В комментариях к одному видео некто задал интересный вопрос:
А должны ли программисты изучать бизнес-сферу проекта, где работают?
Автор видео не успел ответить, а я же посчитал, что меня забыли спросить и что я должен ответить на этот вопрос.
Почему не стоит слепо доверять прописанным требованиям
Некоторые разработчики могут подумать, что они приходят в компанию писать код и разрабатывать архитектуру, а не вдаваться в подробности бизнеса компании. Что, мол, бизнес-аналитики должны прорабатывать все нюансы проекта и сценарии взаимодействия (Use Case - UML). И это значит, по мнению этих разработчиков, что можно не о чем не волноваться, читать требования и воплощать их в жизнь так, как прописаны аналитиком. С одной стороны, такое мнение имеет право на жизнь, однако есть пара проблем:
- бизнес-аналитик может быть недостаточно квалифицированным;
- бизнес-аналитик может быть уставшим;
- бизнес-аналитик может не знать технических нюансов и возможностей;
- у бизнес-аналитика может быть “замыт глаз”
- подставь свой вариант, который опишет еще одну вероятность ошибиться на этапе проработки требований.
Как это может повлиять на программиста? А вроде бы и никак, ведь его задача была реализовать функционал по требованиям, и если требования ошибочны, то и вина лежит на бизнес-аналитике, а не на разработчике. Мне кажется, что такое мышление деструктивно и не приводит к успеху. И вот почему.
Эффективная работа с требованиями задачи
На то, чтобы разработчик вникал в бизнес-сферу, есть две причины.
Во-первых, разработчик должен вникать в бизнес-требования не только потому, что ему претворять их в жизнь, но и для того, чтобы оценить их критическим взглядом “со стороны”. Если разработчик задаст вопросы “а почему так, а не иначе”, то бизнес-аналитик расскажет больше контекста и, возможно, поделится будущими плананми на запрашиваемый сейчас функционал. Так разработчик, во-первых, будет в курсе развития проекта, а во-вторых, сможет учесть эти планы в проработке архитектуры сейчас. Как бонус, бизнес-аналитик может иначе взглянуть на запрашиваемый функционал и, вероятно, упомянуть важные аспекты, которые он забыл внести в основную задачу.
Во-вторых, чем лучше разработчик погружен в бизнес-контекст, тем больше улучшений он может предложить заказчику и аналитикам и тем менее он будет зависим от решения вопросов, которые совсем незначительны и не влияют на изначальные требования. Например, во время реализации задачи разработчик наталкивается на дилемму, описания которой нет в задаче. И тут у него есть три сценария:
- Задать вопрос аналитику и/или продакту (Product Owner) и ждать четких инструкций.
- Продумать и предложить на выбор несколько сценариев решения дилеммы, которые по мнению разработчика будут наиболее эффективны, и ждать решения.
- Сделать то же самое, что и в пункте 2, а затем начать реализовывать тот вариант, который, по мнению разработчика, лучше всего подойдет продукту и ляжет красиво на текущую программную архитектуру.
В первом случае разработчик ведет себя лишь как исполнитель четкой инструкции. И тут нет ничего плохого, однако большую ценность и незаменимость в таком разработчике заказчик врядли увидит. Такому разработчику легко найти замену, и даже вероятно, что замена будет стоить дешевле. А когда разработчик захочет повышения, то вероятность, что заказчик пойдет навстречу ему, крайне мала.
Во втором случае ценность разработчика немного выше. Заказчик уже не должен вникать в контекст, а может отталкиваться от предложенных вариантов и описания их последствий. Таким образом, решение дилеммы будет придумано быстрее с большой долей вероятности. Чем чаще такие случаи будут происходить, тем легче будет разработчику учесть опыт прошлых предожений и делать предложения ценнее для бизнеса и точнее. В свою очередь разработчик делает себя более ценным для заказчика, и на удержание его на проекте пойдут охотнее. Иначе говоря, просить повышения будет легче.
Третий случай немного отличается от второго тем, что разработчик идет на риск, что подход, который он сам выбрал для реализации, не будет выбран заказчиком. Однако я не вижу в этом большой проблемы, ведь, во-первых, полученный опыт можно учесть в реализации утвержденного сценария, а во вторых, вопрос врядли был глобальным, что разные варианты его решения приводили к кардинально разным архитектурным решениям.
Читатель может подумать, разработчик потратил некоторое оплаченное заказчиком время впустую, однако это не так, и вот почему:
- разработчик не виноват, что после этапа аналитики остались вопросы, требующие согласования владельцем продукта;
- разработчик погрузился больше в проблему бизнеса, чтобы предожить варианты решения, и это точно не может характеризоваться как трата времени
- разработчик вырос как самостоятельный и инициативный специалист в глазах заказчика.
В результате этой ситуации разработчик заработал себе очки в карму, и когда он захочет повышения на текущем проекте, бизнес вряд ли откажется от дальнейшего сотрудничества с таким специалистом и примет участия в переговорах о новой зарплате.
Еще одна причина, почему разработчику нужно интересоваться бизнесом
Если бы от разработчиков и не ждали погружения в контекст, а только лишь исполнение четких инструкций от бизнес-аналитиков, то такого разработчика почти ничто не отличает от обычного компьютера. Иначе говоря, разработчик становится механическим переводчиком бизнес-требований, написанных на английском человеческом языке, на язык программный. Правда, еще этот разработчик стоит гораздо дороже компьютера, иногда жалуется на “плохие” условия и периодически требует повышения. А еще может проявлять свой непростой характер. И зачем такой разработчик нужен бизнесу, если можно разработать и использовать специальный инструмент, который бы делал то же самое?
К слову, попыток сделать инструмент, который позволил бы непрограммистам программировать продукт, было много, однако Microsoft, Uber, Google, Yandex и прочие IT-компании продолжают упорно хантить самых лучших разработчиков со всего мира. Не думаю, что они там у себя плачут, колятся, но продолжают есть кактус.
Если разработчику не интересна бизнес-сфера проекта
Такое тоже может быть, и тут могу сказать следующее. Если разработчик не готов проявлять заинтересованность и инииативу, то пусть будет готов, что однажды с ним расстанутся, так как нашли более дешевую замену. Иначе говоря, ваша осведомленность в бизнес-сфере - это ваше конкурентное преимущество.
Так что же теперь делать?
Навыки, полученные во время обсуждений требований, будут полезны разработчику в любом случае. Умение продавать технические улучшения никогда не были лишними, да и от дополнительные знаний бизнеса еще не один разработчик сильно не пострадал. И даже если не интересен текущий проект, то стоит прокачивать вышеописанные навыки для будущего проекта и/или работодателя.