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