Производственная ситуация

На нашем предприятии в числе прочего, разрабатывается ПО.
При этом постановка задачи происходит в одном отделе, разработка ПО по заданным ТЗ – в другом.
Я руковожу отделом, где выполняется постановка. И я отвечаю за конечный результат – и качественно и в сроках. При этом, взаимодействие с отделом разработки дается мне с трудом.
Ситуации, в которых я увязаю, очень похожи, отличаются небольшими вариациями. Все происходит примерно так.
На совместном совещании, в присутствии руководства, принимается решение об определенной новой разработке. Обсуждается стартовое ТЗ, на каком-то этапе отдел разработки его принимает. Отдел разработки сообщает сроки, когда появится первая версия. Наш общий руководитель с ними знакомится.
Проходит время, наступает плановый срок. Я прошу выдать на тестирование ожидаемое ПО. На что руководитель отдела ПО с недоумением и возмущением восклицает – «Как! Какое ПО? Да по тому ТЗ совершено невозможно было работать! Это не документ. Мы и так загружены по самое немогу, и вы хотите чтобы мы тратили время на такие недодуманные бумажки?! Пишите нормальное ТЗ!». По-первости я шла к вышестоящему руководителю, напоминала про принятый в свое время документ, ссылалась на планы. Мне разъясняли, что видимо действительно, постановка была некачественная. Нужно доработать. Начиналась разработка нового документа. Теперь я соглашаюсь с программистами сразу (чтобы сократить один шаг) и прошу сообщить, что именно не понятно. Мне сообщают замечания. Мы дорабатываем документ. Дальше он может вернуться тут же (это не ТЗ!), или быть принятым, названы новые сроки. Дальше все повторяется по кругу. Иногда мы спрыгиваем с круга и получаем продукт. В одном случае из пяти. В оставшихся, многие месяцы происходят однотипные, совершенно предсказуемые итерации. Итоговые сроки выпуска продукта сильно срываются. При этом. Рыночная ситуация может измениться и потребность в продукте снизиться. Что я могу отвечать на вопрос руководителя, почему так вышло? То, что я не умею уговорить программистов?
Отдельно расскажу о замечаниях, выдаваемых на ТЗ. Часть из них, безусловно, по делу. Но очень часто я вижу, что нас затягивают в ловушку. Например, требуют описать, как именно реализовать данную функцию в привязке к нашим существующим программам. Понятно, что мы гораздо хуже программистов представляем внутреннее устройство программ. Поэтому при описании привязок допускаем различные неточности. На них нас ловят, обвиняют в некомпетентности, и получают повод не начинать работу. Пока мы не разберемся и не напишем все «грамотно».
Каждый раз, когда начинается новый круг, я знаю об этом. Как выйти из него –не знаю. Сил и времени на непродуктивную деятельность тратится очень много.

Будучи озадачена вопросом, я почитала кое-какие книги. В частности, Берна (люди, к-е играют…) и Литвака (вампиризм и айкидо). Наверно ошибаюсь, но из описанный примеров, ситуация больше всего похожа на игру «Почему бы вам не… Да но…». Выдавая ТЗ, я предлагаю решение, но оно раз за разом отклоняется. Описано, что выход из такой игры- перестать давать советы. Но как его применить в условиях производства, когда «советчик» отвечает за результат?


И еще заранее отмечу вот что. Руководитель многократно пытался помочь. Например, обещает (и платит) отделу ПО хорошие премии за результат в срок. Бывают и обратные «обещания»-что будет, если результата не будет. Просто уговаривает, объясняя важность и необходимость получать результат. Наверно, это имеет эффект. Тот самый- один случай из пяти.

А как точно называется Ваша должность?

Сообщение отредактировал(а) Conscious - 9.11.2007 - 16:56

Хех... Мне почему-то кажется, что проблема в том, как поставлен процесс разработки в вашей компании.
Где-то посередине между составлением ТЗ и реализацией его в готовый код происходит сбой.
Хочется понять, что ж не так...

- Какой процесс разработки используется? Один из вариантов agile?
- Участвуют ли программисты в составлении/review ТЗ по маркетинговым требованиям?
- Пишется ли High Level Design по ТЗ?
- Есть ли проверка traceability? Являются ли требования из ТЗ testable?
- Как происходит tracking проекта? Можно ли в любой момент времени определить, какие фичи сделаны, какие нет?
- Как составляется проектный schedule по имеющемуся ТЗ? Когда и как проходит replanning?

Сорри, если что-то непонятно... Можно списаться по ICQ/чему-нибудь еще и обсудить все подробнее .

Сорри за ответ в тему вопросы ведущим, просто мне кажется что эта проблема связана именно с процессом разработки.

to Conscious

моя должность так и называется -Начальник отдела систем автоматизации.
как вы выразились в предыдущем ответе- именно "отдела ТЗ".

Все вы там правильно писали, в предыдущем посте (зачем стерли? трудно теперь комментировать).
Но есть особенности. Пойти, как в первый день, как вы писали, было бы с одной стороны нечесно, с другой- приведет ни к тому результату. При благоприятном исходе это поход, конечно, прикроет меня. Но хочется-то не прекрыться (нет такой необходимости), хочется чтоб процесс шел эффективно.

И второе ваше предложение- поменять структуру управления. К сожалению, для данной ситуации невозможно.

Вот можно ли улучшить результаты не меняя существенно окружающий мир - вот что интересно..

Елена, в данном случае вы пожалуй читаете не те книги. Прочитайте Йордона "Путь камикадзе" и Брукса "Мифический человеко-месяц", а также что-нибудь по XP (экстремальному программированию).

Из конкретных рекомендаций можно предложить (а вам - сразу же внедрить!) следующее:

1. Официальное и жесткое письменное согласование ТЗ.

2. Сократить итерации по выпуску продукта до 2-4 недель.
Это значит, что минимум каждый месяц вам отгружают (недоделанный) продукт и вы смотрите, что добавилось. Более слабый, но более простой вариант: еженедельная проверка хода работ. Здесь же вы можете заранее проверить, что ТЗ понято правильно и что оно вообще понято.