Много лет назад меня наняла компания Omni-Corp для работы над новым блестящим продуктом. У нас был талант, бюджет и крутые технологии, но этот проект должен был потерпеть фиаско (и в результате его отменили) меньше чем через год.

Никто не идеален – у нас были свои проблемы, какие-то из них технические, какие-то – нет. Одной из них был способ управления требованиями:

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

Это был неплохой процесс, который было легко объяснить (и соблюдать) с четкими этапами (Требования –> Разработка –> Тестирование) и четким результатом по каждому этапу.

Как и все хорошо изложенные планы, этот не пережил встречи с реальным миром.

Так как люди, занимающиеся продуктом, были «бизнесменами», а не «разработчиками программного обеспечения», они не понимали в полной мере логики того, как разработчики понимают требования, а так как разработчики были «разработчиками», мы создавали свои собственные решениям каждый раз, когда сталкивались с «дыркой в логике» документа с требованиями.

За недоверием и хаосом следует…

Мы (разработчики) могли утверждать, что, так как этого нет в документе, нам пришлось все делать так, как мы сочли правильным – и поэтому один блестящий молодой менеджер принял решение: быстро обновить документ за пять минут до собрания, а потом ткнуть, что «это определенно было указано в документе!».

Теперь у нас была новая проблема – было невозможно писать программное обеспечение с постоянно изменяющимися условиями, поэтому нужно было изобрести «заморозку требований».

Заморозка требований!?

Как вы уже, наверное, догадались, в определенный момент времени документ с требованиями должен был блокироваться, чтобы он больше не обновлялся, и, как и заморозка кода, это не сработало. В один прекрасный момент человек, занимающийся продуктом, обнаружил, что он может скопировать замороженный документ, обновить его и ссылаться на новую версию.

В этот момент это стало просто смешно и непродуктивно – недоверие возрастало, так как обе команды чувствовали, что другая команда пытается их обмануть. Команда разработчиков считала, что продукт пытаются всунуть наполовину готовым, постоянно изменяя функции, в то время как рабочая группа считала, что разработчики постоянно пытаются все блокировать, чтобы искать себе новые поводы не работать.

Таким образом, каждый этап процесса превращался в переговоры между противоположными сторонами – я дошел до той точки, когда я отказывался подписывать требования, пока не прочту их несколько раз и не попрошу начальника перечитать их и убедиться, что они полноценны и не содержат скрытых условий.

Я почувствовал себя юристом! Нет ничего плохого в том, чтобы быть юристом (несколько моих лучших друзей юристы), если только это прописано в твоих должностных обязанностях.

И во всем виноваты были мы

Мы (обе команды) забыли, что наша работа – создавать программное обеспечение в соответствии с требованиями наших потребителей.

Оглядываясь назад на эти времена, я понял кое-что – требования изменяются, даже в идеальном проекте клиенты склонны изменять свое мнение, ошибки исправляются, а новые данные могут заставить нас посмотреть на наш продукт с другой точки зрения. Я работал на многие компании до и после этого, и не раз я встречал мифические проекты с требованиями, которые 100% точно не будут изменяться – даже у самых лучших в своем деле.

Мы боролись с реальностью – где проекты могут изменяться со временем. Если бы только мы с такой же страстью и энергией пытались убедиться, что мы так же легко можем изменять свой код.

Правда заключается в том, что код должен легко изменяться. Реорганизация кода, модульное тестирование, проверки кода и прочие методики разработки программного обеспечения могут помочь вам стать хорошими опытными разработчиками программного обеспечения. Это и было нашей работой – использовать подходящие методики, чтобы предоставить нашим потребителям новые функции и исправления багов как можно быстрее – вместо того, чтобы жаловаться, что требования постоянно изменяются…

Иногда очень сложно вносить изменения в большие и сложные базы кодов. Когда мы вносим изменения, важно убедиться, что мы вносим одно за раз. Слишком часто нам кажется, что мы изменяем только что-то одно, а в результате мы непреднамеренно изменяем другие элементы, и тем самым создаем новые баги.

Майкл Фезерс – эффективная работа с унаследованным кодом

Это довольно просто – простой код означает простоту его изменения. Поэтому убедитесь, что вы делаете свою работу, прежде чем пытаться изменить мир.

Счастливого вам (и чистого) кода…