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