Авторы: Алексей Янчук, Константин Кондратюк

В предыдущем блоге мы остановились на мысли, что менеджмент и ИТ — это «до безобразия просто». А если говорить серьёзно — почему в реальной жизни все совсем не так: менеджмент в ИТ — это сложная, тяжелая и порой неблагодарная работа?

Если пытаться дать краткий ответ на этот вопрос, то вот почему. Проектная деятельность осуществляется в определенной среде и в определенном контексте. Напрямую, «копи-пастом», прошлый опыт переносить не то что не получается — чаще всего просто опасно. Приходится думать головой, получается не всегда и не у всех. Есть и длинная версия ответа на этот вопрос, которую мы и рассматриваем в этой серии блогов.

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

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

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

Проблема в другом — в том, что оценка так или иначе сводится к некоторым цифрам, которые рассчитаны на основе предположений, которые а) нередко делаются где-то на уровне подсознания, б) этих предположений слишком много, чтобы их все объяснить простыми словами за 30 секунд, в) они требуют какого-никакого опыта или образования для интерпретации, и г) скорее всего не могли быть проверены оценщиками. Может ли отдел разработки донести до продавцов, на чем основаны их цифры?

Честно говоря, чаще всего — нет. Продавец попытается выслушать, не поймет ничего из того, что ему объясняют, зато с радостью прицепится к цифрам, и с этими цифрами побежит договариваться насчет контракта и его цены. Когда цифры оценки пересчитаны в бюджет проекта и этот бюджет озвучен клиенту, начинается торг. Примитивный торг за деньги, и ничего более. Как должен продавец отреагировать на фразу заказчика «Нас удивила такая высокая оценка. Ваши конкуренты предложили минимум в два раза меньше»? Или «в вашем предложении вот тут стоит цифра 60%. Ваши конкуренты предлагают не менее 80%». Да, это «ссылочная манипуляция» в чистом виде; но что прикажете делать продавцам, которые сидят за столом переговоров и должны что-то ответить? О, часто это вопрос на миллион долларов. В прямом смысле.

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

Почему так происходит? Потому что считается, что программисты не в состоянии ни разговаривать с заказчиками, ни адекватно вести себя при переговорах. Это действительно так в силу весьма объективных причин. Конечно, было бы не лишним, чтобы:

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

С другой стороны, если отдел разработки объясняет оценки так, что у отдела продаж не шансов понять, то кто же тут не прав? С нашей точки зрения неправы трое: оба отдела и те, кому эти отделы отчитываются. Общение — это процесс, в котором все участники должны понимать друг друга. Если одна сторона хронически не в состоянии понять другую, то это значит лишь то, что нет общения. Отсутствие взаимопонимания между разработчиками и продавцами стоит компании упущенной прибыли. И какое счастье, что ее никто не пытается оценивать.

Умение общаться это как умение плавать. Вроде как все умеют и все должны. А сколько людей умеют правильно плавать? Очень немного. Хорошая новость в том, что общение — это навык, которому можно научиться, если над его развитием сознательно работать. И отдел разработки, который умeет изъясняться так, чтобы его понимали, будет в состоянии сгенерировать больше прибыли для компании.

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