Автор: Крис Шелдон, Senior Project Manager, DataArt 

Что происходит, если поспешить углубиться в детали и слишком надолго сосредоточиться на написании кода? Почему стремление к техническому совершенству не всегда радует заказчика? 12 лет назад Крис Шелдон, менеджер проектов DataArt из Лондона, был начинающим разработчиком, уверенным, что навыки программирования — все, что ему понадобится в профессии.

Опыт провала его первого самостоятельного проекта наглядно демонстрирует, зачем техническим специалистам учиться разговаривать с представителями бизнеса и друг с другом. 

Зачем взрослые люди учатся разговаривать

Недавно я записался на учебный курс по развитию софт скилз для IT-специалистов. Говорим там в основном о культурных различиях: в нашей индустрии мы постоянно окружены множеством умных людей, но иногда манера общения, характерная для одной страны, мешает выходцу из другой понять коллегу.

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

Далеко не всем разработчикам и QA-инженерам очевидна ценность такого дополнительного образования. Зачем вдруг взрослому человеку, тем более хорошему специалисту в своей области, учиться разговаривать? Что это за навык, и какой от него прок в мире серьезной разработки?

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

Делать свое дело вне зависимости от обстоятельств

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

Речь шла об ATS — системах управления кандидатами, которые позволяли частично автоматизировать процесс найма выпускников.

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

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

Прошло шесть месяцев, я освоил все существующие в компании системы и стал в сто раз больше понимать в программировании. У нас появился баг-трекер, а разбираться с багами как раз поручили мне, и я старался делать это с максимальной скоростью. Рабочий процесс был налажен: список ошибок был доступен онлайн, и клочки бумаги с требованиями исчезли без следа. Каждый устраненный баг обеспечивал мне небольшую дозу дофамина, так что работа мне нравилась.

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

Каждую клиентскую систему мы разрабатывали индивидуально по единой методологии:

1. Копировали существующую систему.
2. Вносили в копию изменения, пока все требования не будут учтены.

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

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

Когда система наконец оказалась готова для презентации клиенту, я был чрезвычайно доволен собой. Плюс ко всему, я как раз закончил обучение нескольких джунов (один из которых был сильнее меня как программист), которых наняли помочь мне в проекте.

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

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

За время разработки системы я ни разу не поговорил с клиентом — я был поглощен техническим совершенством своего творения. Я хотел создать нечто, подходящее для масштабирования, улучшенную платформу для копирования в расчете на перспективные изменения. О том, какими функциями системы и каким именно образом будут пользоваться реальные люди, я совершенно не задумывался.

Отзыв клиента был, мягко говоря, эмоциональным: «И где в этой форме поле для номера разрешения на работу? Как людям подавать документы?!» Надо ли уточнять, что я о таком поле слышал впервые. Проект потребовал множества изменений, и уровень кастомизации системы в итоге оказался куда более значительным, чем я мог предполагать. 

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

Agile: больше никаких листочков

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

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

Потом мне поручили еще несколько проектов, я постепенно восстановил репутацию. Так что когда оговоренные шесть месяцев истекли, покидать компанию оказалось грустно.

Но перед уходом работодатель успел сделать мне настоящий подарок в виде проекта новой системы на современном по тогдашним меркам языке программирования. Мы переходили с Classic ASP на ASP.NET WebForms: копировать целые системы теперь было не нужно. Проект подразумевал сотрудничество по принципу White Label и фактически открывал новую техническую эру для компании.

К сожалению, в команду этого проекта я не входил, но меня допускали на ежедневные совещания, где обсуждалось его развитие. Там я впервые услышал об Agile-методологии, с помощью которой можно разделять разработку на удобные фрагменты, убеждаясь в ценности каждого из них для бизнеса.<

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

<Оглядываясь на тот период своей карьеры, я четко вижу, насколько важны два этих компонента Манифеста гибкой разработки:

1. Взаимодействие с клиентом.
2. Реакция на изменение требований.

Угроза изоляции

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

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

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

Вот потому я до сих пор убежден, что налаженная коммуникация важнее технических знаний.