Что делать? Убедитесь, что вы хотя бы с руководителем проекта разговариваете на одном языке. Как в плане постановки задач, так и в расчете сроков. Используйте для разработки ТЗ костыли наподобие "user stories", поможет сократить сроки. Если не можете составить их сами - нанимайте специалиста. РП на неделю к себе в команду, да.
Этап 3: Разработка А вот здесь начинается самое интересное. Предположим, случилось чудо и вы с первого раза попали на адекватную (хотя бы внешне) IT-студию и даже умудрились согласовать ТЗ быстрее, чем за полгода. Студия берется за работу. В ней есть, предположим, 1 тимлид, 2 разработчика уровня senior, 4-5 middle'ов и пара десятков junior (возможно, вам их даже показали). В мечтах заказчика вся эта команда слаженно берется за работу и делает красивый, цельный, задокументированный проект примерно месяца за два.
А теперь расскажем, что происходит в реальности. У студии в работе уже 18 проектов, из них 3 с безбожно сорванными дедлайнами (на грани отказа клиента), 5 на финальной стадии (с бесконечными мелкими правками), а оставшиеся 10 на разных стадиях готовности.
Тимлид сидит с больной головой и занимается уже исключительно раскидыванием обязанностей под прессом своих же аккаунт-менеджеров. Оба senior'а разрываются между ключевыми задачами заказчиков и работой над пилотным проектом самой студии, который захотел лично директор. Middle'ы не знают куда податься: то ли помогать senior'ам, то ли контролировать работу jumior'ов, то ли заняться наконец документированием всех 18 проектов, до которого руки еще не дошли ни у кого.
Junior'ы… а что junior'ы? В отсутствии внятно поставленных задач (всем не до них) они творят некий код. Если звезды сошлись удачно, сотворенный разными джунами код впоследствии можно будет собрать в подобие рабочего модуля и этот модуль случайно окажется именно тем, что хотел хотя бы один клиент из восемнадцати. Если нет - люди просто получат свой оклад, а в следующем месяце (когда хоть кто-то спохватится и даст им четкие задачи) начнут писать
нужный код. Потом выяснится, что клиент устал ждать и заказал этот модуль на стороне и этот код менеджеры будут пытаться продать другому клиенту, для чего его нужно будет адаптировать.
Конечно мы сознательно усугубили описание ситуации. Однако в профессиональной среде об этой проблеме известно давно. На Хабре масса профильных обсуждений. Программисты размышляют на тему "
Почему мы пропускаем дедлайны, и как с этим бороться". Руководители делятся опытом "
Как подсознательно побудить сотрудников соблюдать дедлайны проекта"
Впрочем, чему удивляться, если для менеджеров проектов пишут вот такие вредные советы:
Вас не должны любить! Любовь — это лишнее в современном жестоком мире. Вас должны бояться, обсуждать, на вас должны работать. Не просто работать, а пахать от ночи до зари! И запомните: центр креатива — это вы. Только вам решать, что должно быть в проекте. Все комментарии и исправления заведомо признавайте как унылое... просто плохую идею
Источник: https://career.ru/article/10945 Если у подрядчика руководитель проекта и разработчики стоят по разную сторону баррикады, продуктивной работы не будет никогда. Шанс получить в этой студии свой заказ вовремя и в соответствии с ТЗ вы уже представили, правда?
Конечно есть хорошии студии с распределением нагрузки и соблюдением дедлайнов. Но шанс наткнуться на хорошую студию с первого раза мы уже обсуждали.
Этап 4: Получение результата Сроки сорваны, проект не готов.
Если хотите получить достоверную статистику сорванных дедлайнов - спрашивайте не у менеджеров, а у разработчиков. А
они ответят, что если студия не использует Agile-подход в разработке, то проваливаются сроки реализации четырех задач из пяти, а если использует, то примерно двух-трех из пяти. С учетом того, что в проекте задач не одна и не две, то общий дедлайн срывается почти всегда.
Вы начинаете нервничать и отправляете ключевого сотрудника разобраться с ситуацией. Встречи с аккаунт-менеджерами студии становятся вдвое чаще, а их улыбки втрое шире. Вас уверяют, что проект "вот-вот". Спустя два месяца "вот-вотов" вам показывают некий функционал. В лучшем случае он примерно похож на то, что было прописано в ТЗ и охватывает процентов двадцать ваших пожеланий. Но проект, готовый на 20% для вас бесполезен на все 100 - вы не можете начать работу с клиентами, пока он не готов.
И вот наступает момент Х: вы не можете больше ждать и уведомляете студию о готовности отказаться от их услуг, если они не закончат проект за месяц. Вашим вопросом занимается лично директор студии и берет дело "на особый контроль". Смотрим, что происходит внутри студии в этот момент.