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

-«Здравствуйте, чего не открываете?»
-«Так мы вроде бы никого не ждали сегодня..»
-«Как же не ждали? День сегодня какой? Договаривались же…»

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

-«Пройдемте в переговорку. Чай? Кофе?»

Оставьте лирику, займемся гипнозом

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

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

Картина «Всё по-взрослому»

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

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

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

Картина «Я у мамы дизайнер»

Диспозиция: у вас небольшая, но разноплановая команда (фронт, бэк, тестирование), по разным причинам проект долго буксовал, но в последние месяцы летит на всех парусах, чтобы успеть в срок. Заказчик — то ли крупная корпорация, то ли и вовсе государство, и его представитель периодически просит показать результат работы в формате демо-показа по скайпу. Руководитель фронтенда проводит показ и все выглядит так, будто в него вселился Стив Джобс — в конце заказчик уйдет вечно голодным и безрассудным. Красивая речь словно убаюкивает остальных, отключивших микрофон… Затишье перед бурей. Снова эта манера повествования, ничего не могу поделать.

Реальность: резко, словно удар кинжала, заказчик бросает вопрос: «А почему у вас кнопка удаления не там, где кнопка редактирования?». (Р — разработчик, З — заказчик)

-Р:«Так мы руководствовались макетами, которые согласо..»
-З:«Да это же неудобно, перенесите её».
Вялое эхо одобрения.
-З:«А возможно, чтобы каждый пользователь мог настраивать себе расположение кнопкок?»
-Р:«Да, но может мы сперв..»
-З«А вот тут у вас что? Эту вкладку, её же лучше сделать сворачиваемой».
-Р:«Да, конечно, подумаем тогда как это переработать».
-З:«Ну и над цветом конечно лучше подумать, может быть тут синий больше подойдет».
К концу часа все присутствующие понимают, что столько парусины им не найти.

Вердикт: классика жанра. Мораль сей басни в том, что иногда нужно уметь говорить нет, иногда признавать свои ошибки, а иногда твердо стоять на своем. Как именно поступить, зависит от конкретной ситуации. Если всегда иметь «лихой и придурковатый вид» подчиненного из петровского указа, то проект рискует быть незаконченным, сделка сорванной. Но важнейшим вопросом здесь является не «как поступить», а «кому поступить». Постараемся найти ответ в заключении.

Итого

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