Много лет назад меня наняла компания Omni-Corp для работы над новым блестящим продуктом. У нас был талант, бюджет и крутые технологии, но этот проект должен был потерпеть фиаско (и в результате его отменили) меньше чем через год.
Никто не идеален – у нас были свои проблемы, какие-то из них технические, какие-то – нет. Одной из них был способ управления требованиями:
Человек, занимающийся продуктом, мог создать текстовый документ с описанием новой функции. После нескольких совещаний и согласования разработки по характеристикам этой функции начинал писаться код. В конечном итоге тестеры могли использовать этот текстовый документ для создания планов тестирования и проверки того, насколько эти требования соблюдаются.
Это был неплохой процесс, который было легко объяснить (и соблюдать) с четкими этапами (Требования –> Разработка –> Тестирование) и четким результатом по каждому этапу.
Как и все хорошо изложенные планы, этот не пережил встречи с реальным миром.
Так как люди, занимающиеся продуктом, были «бизнесменами», а не «разработчиками программного обеспечения», они не понимали в полной мере логики того, как разработчики понимают требования, а так как разработчики были «разработчиками», мы создавали свои собственные решениям каждый раз, когда сталкивались с «дыркой в логике» документа с требованиями.
Мы (разработчики) могли утверждать, что, так как этого нет в документе, нам пришлось все делать так, как мы сочли правильным – и поэтому один блестящий молодой менеджер принял решение: быстро обновить документ за пять минут до собрания, а потом ткнуть, что «это определенно было указано в документе!».
Теперь у нас была новая проблема – было невозможно писать программное обеспечение с постоянно изменяющимися условиями, поэтому нужно было изобрести «заморозку требований».
Как вы уже, наверное, догадались, в определенный момент времени документ с требованиями должен был блокироваться, чтобы он больше не обновлялся, и, как и заморозка кода, это не сработало. В один прекрасный момент человек, занимающийся продуктом, обнаружил, что он может скопировать замороженный документ, обновить его и ссылаться на новую версию.
В этот момент это стало просто смешно и непродуктивно – недоверие возрастало, так как обе команды чувствовали, что другая команда пытается их обмануть. Команда разработчиков считала, что продукт пытаются всунуть наполовину готовым, постоянно изменяя функции, в то время как рабочая группа считала, что разработчики постоянно пытаются все блокировать, чтобы искать себе новые поводы не работать.
Таким образом, каждый этап процесса превращался в переговоры между противоположными сторонами – я дошел до той точки, когда я отказывался подписывать требования, пока не прочту их несколько раз и не попрошу начальника перечитать их и убедиться, что они полноценны и не содержат скрытых условий.
Я почувствовал себя юристом! Нет ничего плохого в том, чтобы быть юристом (несколько моих лучших друзей юристы), если только это прописано в твоих должностных обязанностях.
Мы (обе команды) забыли, что наша работа – создавать программное обеспечение в соответствии с требованиями наших потребителей.
Оглядываясь назад на эти времена, я понял кое-что – требования изменяются, даже в идеальном проекте клиенты склонны изменять свое мнение, ошибки исправляются, а новые данные могут заставить нас посмотреть на наш продукт с другой точки зрения. Я работал на многие компании до и после этого, и не раз я встречал мифические проекты с требованиями, которые 100% точно не будут изменяться – даже у самых лучших в своем деле.
Мы боролись с реальностью – где проекты могут изменяться со временем. Если бы только мы с такой же страстью и энергией пытались убедиться, что мы так же легко можем изменять свой код.
Правда заключается в том, что код должен легко изменяться. Реорганизация кода, модульное тестирование, проверки кода и прочие методики разработки программного обеспечения могут помочь вам стать хорошими опытными разработчиками программного обеспечения. Это и было нашей работой – использовать подходящие методики, чтобы предоставить нашим потребителям новые функции и исправления багов как можно быстрее – вместо того, чтобы жаловаться, что требования постоянно изменяются…
Это довольно просто – простой код означает простоту его изменения. Поэтому убедитесь, что вы делаете свою работу, прежде чем пытаться изменить мир.
Счастливого вам (и чистого) кода…
Никто не идеален – у нас были свои проблемы, какие-то из них технические, какие-то – нет. Одной из них был способ управления требованиями:
Человек, занимающийся продуктом, мог создать текстовый документ с описанием новой функции. После нескольких совещаний и согласования разработки по характеристикам этой функции начинал писаться код. В конечном итоге тестеры могли использовать этот текстовый документ для создания планов тестирования и проверки того, насколько эти требования соблюдаются.
Это был неплохой процесс, который было легко объяснить (и соблюдать) с четкими этапами (Требования –> Разработка –> Тестирование) и четким результатом по каждому этапу.
Как и все хорошо изложенные планы, этот не пережил встречи с реальным миром.
Так как люди, занимающиеся продуктом, были «бизнесменами», а не «разработчиками программного обеспечения», они не понимали в полной мере логики того, как разработчики понимают требования, а так как разработчики были «разработчиками», мы создавали свои собственные решениям каждый раз, когда сталкивались с «дыркой в логике» документа с требованиями.
За недоверием и хаосом следует…
Мы (разработчики) могли утверждать, что, так как этого нет в документе, нам пришлось все делать так, как мы сочли правильным – и поэтому один блестящий молодой менеджер принял решение: быстро обновить документ за пять минут до собрания, а потом ткнуть, что «это определенно было указано в документе!».
Теперь у нас была новая проблема – было невозможно писать программное обеспечение с постоянно изменяющимися условиями, поэтому нужно было изобрести «заморозку требований».
Заморозка требований!?
Как вы уже, наверное, догадались, в определенный момент времени документ с требованиями должен был блокироваться, чтобы он больше не обновлялся, и, как и заморозка кода, это не сработало. В один прекрасный момент человек, занимающийся продуктом, обнаружил, что он может скопировать замороженный документ, обновить его и ссылаться на новую версию.
В этот момент это стало просто смешно и непродуктивно – недоверие возрастало, так как обе команды чувствовали, что другая команда пытается их обмануть. Команда разработчиков считала, что продукт пытаются всунуть наполовину готовым, постоянно изменяя функции, в то время как рабочая группа считала, что разработчики постоянно пытаются все блокировать, чтобы искать себе новые поводы не работать.
Таким образом, каждый этап процесса превращался в переговоры между противоположными сторонами – я дошел до той точки, когда я отказывался подписывать требования, пока не прочту их несколько раз и не попрошу начальника перечитать их и убедиться, что они полноценны и не содержат скрытых условий.
Я почувствовал себя юристом! Нет ничего плохого в том, чтобы быть юристом (несколько моих лучших друзей юристы), если только это прописано в твоих должностных обязанностях.
И во всем виноваты были мы
Мы (обе команды) забыли, что наша работа – создавать программное обеспечение в соответствии с требованиями наших потребителей.
Оглядываясь назад на эти времена, я понял кое-что – требования изменяются, даже в идеальном проекте клиенты склонны изменять свое мнение, ошибки исправляются, а новые данные могут заставить нас посмотреть на наш продукт с другой точки зрения. Я работал на многие компании до и после этого, и не раз я встречал мифические проекты с требованиями, которые 100% точно не будут изменяться – даже у самых лучших в своем деле.
Мы боролись с реальностью – где проекты могут изменяться со временем. Если бы только мы с такой же страстью и энергией пытались убедиться, что мы так же легко можем изменять свой код.
Правда заключается в том, что код должен легко изменяться. Реорганизация кода, модульное тестирование, проверки кода и прочие методики разработки программного обеспечения могут помочь вам стать хорошими опытными разработчиками программного обеспечения. Это и было нашей работой – использовать подходящие методики, чтобы предоставить нашим потребителям новые функции и исправления багов как можно быстрее – вместо того, чтобы жаловаться, что требования постоянно изменяются…
Иногда очень сложно вносить изменения в большие и сложные базы кодов. Когда мы вносим изменения, важно убедиться, что мы вносим одно за раз. Слишком часто нам кажется, что мы изменяем только что-то одно, а в результате мы непреднамеренно изменяем другие элементы, и тем самым создаем новые баги.
Майкл Фезерс – эффективная работа с унаследованным кодом
Это довольно просто – простой код означает простоту его изменения. Поэтому убедитесь, что вы делаете свою работу, прежде чем пытаться изменить мир.
Счастливого вам (и чистого) кода…
Полезные решения Paysto для читателей Мегамозг:
> Получите оплату банковской картой прямо сейчас. Без сайта, ИП и ООО.
> Принимайте оплату от компаний через Интернет. Без сайта, ИП и ООО.
> Приём платежей от компаний для Вашего сайта. С документооборотом и обменом оригиналами.
> Автоматизация продаж и обслуживание сделок с юр.лицами. Без посредника в расчетах.
> Принимайте оплату от компаний через Интернет. Без сайта, ИП и ООО.
> Приём платежей от компаний для Вашего сайта. С документооборотом и обменом оригиналами.
> Автоматизация продаж и обслуживание сделок с юр.лицами. Без посредника в расчетах.
Комментарии (3)
VYBGSS
14.05.2015 11:29недоверие возрастало, так как обе команды чувствовали, что другая команда пытается их обмануть
Значит плохой менеджер, который не смог на этом этапе (а лучше — еще раньше) увидеть указанную проблему и разрешить ее.
alexey_uzhva
15.05.2015 23:07Проблема у вас в управлении, а не в модульности.
После каждого изменения требований должна производиться его оценка на другие проектные ограничения — срок, бюджет, команду. Результат согласовываться с владельцем продукта.
Если он принимает этот эффект, работаете спокойно. Если цена оказывается не адекватна бизнес-ценности — он откажется сам. Если вы не можете оценить эффект и внятно его рассказать — у вас пока мало опыта, учитесь.
Ибо даже идеальный код бессилен перед изменением требований за день до релиза.
vayho
Ситуация когда лид читает ТЗ несколько раз и утверждает его вполне нормальна и адекватна. У меня был подобный опыт работы, где каждое звено тесно работало друг с другом(заказчик ставит задачу, аналитики от заказчика и исполнителя составляют тз, разработчики и тестировщики исполнителя оценивают полноту требований). В такой ситуации аналитик и лид часто немного погружались в обязанности друг дгуга(лид погружался в предметную область, а аналитик умел понимать элементарный код). Но в итоге это давало плюс, в большинстве случаев ТЗ оценивались адекватно. и делались в срок, а если были просчеты то они были минимальны.
В этой ситуации обязанности человека выше(менеджера) дать понять сотрудникам что все они делают общее дело и конфликты не приносят ничего кроме разрушения.
После этой работы я ушел на другую где связь между отделами отсутствует по сути, а аналитиков и тестировщиков нет вообще. Поэтому поставнока задачи в три предложения это нормально, остальное разраб додумывает сам. Издержки которые это все порождает катастрофичны, проект который можно сделать в течении 7-8 месяцев растягивается на 2+ года.