Рассмотрим обычный пример из жизни обычных программистов в такой компании: разрабатывается большая система X, в которой много чего сложного и интересного (а иногда — не очень интересного) — и бизнес работает вполне успешно, и программисты есть, и менеджеры/аналитики — как связующее звено между бизнесом и программистами. Все вроде бы ровно, отлажено, работает. И кода много, и багов. И актуальной документации зачастую днем с огнем не сыщешь… В общем, все «как у всех». Жить можно.
И представим себе ситуацию: есть менеджер (аналитик) Маша, исходя из потребностей заказчика Иван Иваныча (ИИ) соорудившая некое техническое задание (ТЗ) для программиста Васи, в котором сказано что-то вроде «Взять функционал из места A системы X и повторить его в месте B (системы Y)». Иначе говоря — «Сделать как здесь», без подробного описания всех технических деталей реализации.
Такая ситуация несет в себе огромные риски.
Первое: программист Вася может неправильно понять ТЗ и при отсутствии привычки Васи задавать вопросы, а также постоянного контроля со стороны Маши или непосредственного начальника Пети сделать полную фигню. Если Вася является типичным программистом — это с определенной степенью вероятности может произойти.
Второе: в случае, если Маша / Петя все-таки «держат руку на пульсе», а непонимание ТЗ Васей все-таки вызывает у него ряд вопросов к Маше и Пете. В лучшем случае Маша, Петя и Вася в итоге как-то худо-бедно договорятся и в итоге, истратив немеряное количество нервов, сломав десяток копий, съев пуд соли и получив дюлей от ИИ за срыв сроков, все-таки посредством Васиных натруженных до мозолей мозгов реализуют функционал, более-менее или даже полностью соответствующий требованиям заказчика.
Наступит очевидное и недолговечное счастье для всех. Вася будет играть в любимый Counter Strike, Маша — делать карьеру, Петя — всецело и без остатка отдаваться общению с семьей и поездке в Турцию, а ИИ как настоящий капиталист — считать прибыли. Ровно до тех пор, пока реализованный функционал не потребуется существенно изменить/переделать. И тогда наступает новый виток разбирательств в недокументированном коде, непродуманной архитектуре, попыток все переделать. В общем, обыкновенный трудовой процесс настоящих трудяг от IT. Месяцы и годы, потраченные на это, не считает никто, кроме, может быть, жен программистов.
Третье: если Вася по каким-либо причинам «уперся» (например, у него возник личный конфликт с Машей или Петей на почве психоэмоционального стресса, вызванного общим переутомлением и состоянием аффекта от увиденного кода или же просто авральным зарабатыванием денег на ипотеку), либо в компании дела обстоят не очень, или Маша (или Петя, или Вася — неважно) преследуют какие-либо личные цели (например, выдвижение Маши в ведущие аналитики, которого она добивается всеми доступными способами, включая совсем уж неэтичные), либо по еще каким-либо причинам — в этом случае все может обернуться плохо: как для Маши/Васи/Пети, так и для заказчика/системы в целом. Копий сломано будет еще больше, про нервы, репутацию и общее отношение я даже не говорю; а соли будет съеден уже не пуд, а целый КАМАЗ. Про сроки выполнения задачи вообще речи нет. И это при условии, что никто не уйдет, плюнув на все это (или его не «уйдут») и задача/проект вообще не будет загублен.
Ситуация потенциально не выгодна никому: ни Васе, ни Маше, ни Пете, ни ИИ и его бизнесу в целом. Но, тем не менее, такое происходит довольно часто и повсеместно.
Вопрос: что делать, чтобы не попасть в такую ситуацию?
ИИ: Работать на развитие. Мыслить не только категориями бизнеса («моему бизнесу нужно зарабатывать на вот этом — и я дам на это денег, а на все остальное — нет»), но и категориями развития. Как вариант — не экономить и завести себе хорошего CEO, который сможет сработаться со всеми, грамотно распределить задачи и приортеты и выстроить рабочий процесс. Как вариант — сделать CEO Петю, «подрастив» его. Неважно, все зависит от конкретной ситуации и наличия времени и ресурсов. В общем, ключевое слово здесь — «хорошего».
Маше: Работать на развитие. Причем не только собственное. Несмотря на все стремление делать карьеру, все-таки в подробностях описывать все технические детали предстоящего ТЗ. Менеджер/аналитик, не разбирающийся (или не желающий разбираться) во всех технических тонкостях — априори не есть хороший менеджер/аналитик; тут, скорее всего просто стремление сделать карьеру, и ничего более.
Пете: Работать на развитие. Улучшать архитектуру системы. Вникать в то, что именно делает Вася. Не позволять плодить говнокод плохо — ни Васе, ни Маше, ни даже ИИ. Вникать в то, чего хочет ИИ и чего хочет Маша. Иногда это разные вещи. 🙂 Выделить Васе один день в неделю, который он будет тратить на улучшение интерфейсов, оптимизацию кода, выкашивание багов, etc. И при этом не слушать ни Машу, ни ИИ, если они пытаются программиста в указанное время у него «отобрать».
Васе: Работать на развитие. Заниматься не только задачами, которые ставит непосредственное начальство на работе: изучать (или даже написать) какой-нибудь интересный фрэймворк, создать интересный сайт или сервис, вести блог. Быть в курсе современных тенденций в IT и не зацикливаться. Выйти из «зоны комфорта». И иногда думать не как программист, а как менеджер, аналитик, Петя, Маша, ИИ и сам Лысый Черт вместе взятые. Задавать вопросы, в том числе самому себе. Если крыша не поедет.
И тогда, возможно, у Васи, Пети, Маши и ИИ в итоге получится хороший и качественный продукт.
ссылка на оригинал статьи http://habrahabr.ru/post/198850/
Добавить комментарий