Изображение с сайта tech.co
От некоторых сотрудников ИТ-компаний до сих пор можно услышать такую реплику: «Я не совсем понимаю точное значение должности Технический директор». Как отметил в предельно простой форме один из пользователей «Тостера», «CTO — технический человек, который что-то понимает в бизнесе». Если рассматривать это понятие чуть шире, то можно сказать, что он балансирует на стыке между разработкой ИТ-продуктов с командой технических специалистов и принятием бизнес-решений совместно с менеджерами.
Соответственно, для специалистов, желающих занять позицию технического директора в ИТ, существует, как минимум два пути:
- стандартный — «Developer -> Senior -> Team lead -> CTO»;
- гуманитарный – «PM -> Senior PM -> CTO».
Безусловно, в случае второго варианта понимать технические нюансы техническому директору может быть сложнее.
Но достигнув желаемого, в целом, опытный специалист переходит как бы в разряд начинающих. Он становится этаким Junior-CTO и сталкивается с новыми вызовами.
О том, какие ошибки и подводные камни ожидают новоиспеченных технических директоров в ИТ-сфере, мы попросили рассказать экспертов отрасли.
Виктор Шабуров, предприниматель, инвестор и один из основателей компаний Looksery Inc., Handster Inc. и SPB Software
Насколько часто начинающий технический директор ошибается с дедлайнами?
Это типичная ошибка почти всех СТО из СНГ — стараются показать себя наиболее эффективными, что умеют все быстро делать. Я даже не борюсь с этим — бесполезно. Просто удваиваю их сроки в своих оценках.
Какие случаи можете вспомнить?
Да это 100% случаев. Иногда удается объяснить СТО, что ему самому надо сроки удваивать, когда наверх даешь, но команде не говорить. Команду гнать по начальному плану — тогда получается вовремя все сделать.
Насколько это важно для вас?
Не важно, поскольку я уже вошел в дзен и с этим смирился, как с неизбежным природным явлением. Просто надо удваивать их сроки.
Насколько часто начинающий технический директор ошибается с постановкой и распределением задач среди сотрудников?
В принципе мне везло всегда работать с хорошими СТО. Они наверно часто ошибались, но хорошо следили. Через пару дней видно, если задачи распределены неправильно, и они эту проблему решали.
Насколько это важно для вас?
Если СТО внимательно следит за работой — это не проблема, быстро можно исправить.
Какие специалисты больше страдают от ошибок технического директора? Тестировщики, разработчики, проект-менеджеры? Какие случаи можете вспомнить?
Тьфу-тьфу — все СТО, с которыми я работал были отличными. Особенно везло СТО Handster (а потом Opera Software) Алексу Решетько — ему сначала нужно было запустить Hewlett Packard Appstore на Новый Год, а позже Opera Appstore снова на Новый Год, оба проекта за пару месяцев. Вся команда стояла на ушах в праздники, никто не пил и не спал.
Выкатили аппсторы на многомиллионную базу, было очень страшно оба раза — но запуски прошли отлично. Opera Appstore за год вырос до 100М ежемесячных пользователей.
Воспринимаете ли вы ошибки начинающего технического директора, как просчеты старшего товарища или как некомпетентность руководителя? Сможет /должна ли команда «воспитывать/выращивать» технического директора?
Техническую компетенцию человек может набрать. Но ответственность должна быть изначально — если ее нет, надо сразу менять человека, это не выращивается. Обычно это видно на интервью.
Какие случаи можете вспомнить?
Наиболее яркий случай – это, наверное, Юрий Монастыршин, который руководил технической стороной Looksery. Ответственность была очень высокая и правильный подход ко всем проблемам — их надо решать сейчас.
Для меня до сих пор загадка, как он (будучи студентом 5-го курса) справился с созданием проекта, которым сейчас пользуются сотни миллионов людей и который генерирует несколько миллиардов просмотров в день.
Дмитрий Шашлов, iOS-разработчик:
Насколько часто начинающий технический директор ошибается с дедлайнами? Какие случаи можете вспомнить? Насколько это важно для вас?
«Издревле на Руси» дедлайном стали обозначать дату, показав результат к которой, все вокруг будут просто пищать от того, насколько ты круто и четко все сделал и сдал. При всем при этом, почему-то, все майлстоуны тоже неведомым образом стали дедлайнами и если в них не укладываться, то пиши пропало, всем конец, тендер проигран и вообще с нами никто и никогда больше работать не будет.
Выходить за изначально поставленные сроки — естественно для большинства задач на рынке (начинаете работу только по ТЗ?), просто нужно уметь правильно анализировать и аргументировать, почему вы вышли из сроков, какие факторы на это повлияли, и какие меры предприняты, чтобы повторения ситуаций, аналогичных этой, в дальнейшем не произошло.
Насколько часто начинающий технический директор ошибается с постановкой и распределением задач среди сотрудников? Какие случаи можете вспомнить? Насколько это важно для вас?
Команды, в которых мне доводилось больше всего работать на 80% состоят из технарей до 30, среди которых достаточно распространены следующие реакции на постановку задачи:
— A. «Я не уверенно себя чувствую в задаче, подобную которой никогда раньше не делал»
— B. «Сверстать сайт? Отлично, я заодно разберусь как парсить на Perl'e»
— C. «Делать джойны по таблицам — для малолеток, дайте мне уже какую-нибудь нормальную задачу!»
— D. «В форме будет валидатор? Если нет — 8 часов, если будет, то 10-12.»
А дальше — конструктор: там, где нужно исследовать силами B, будет нерационально использовать D, в силу своего рационального расчета; если дать в помощь A товарища C — но и первый будет заряжен, и у второго зудеть перестанет. Так что, наверное, самое важное не быть безучастным, и применить смекалку.
Какие специалисты больше страдают от ошибок технического директора? Тестировщики, разработчики, проект-менеджеры? Какие случаи можете вспомнить? Насколько это важно для вас?
Если технический директор имеет достаточно опыта управления, то все задачи, решение которых может привести к ошибкам, критичным для дальнейшего процесса, как правило, делегируются на технических сотрудников, занимающихся непосредственным исполнением задания (либо их тимлидов), — в результате страдают потом эти самые сотрудники от своих же решений.
Тут многое зависит от организационного уровня, на котором принимаются решения — в различных ситуациях могут «пострадать» как отдельные сотрудники (принял решение, близкое себе, невзирая на контекст, в котором требуется решение), так и вся команда (на просчет технического задания было передано недостаточное количество исходных данных, не было обращено внимание на отдельные важные для реализации моменты, менеджмент производился без понимания необходимой последовательно реализации продукта).
Но, безусловно, важно не уметь не совершать ошибок, а уметь извлекать из них правильные выводы: в чем заключалась ошибка планирования, кому из сотрудников нужно давать больше/меньше свободы принятия решения, каким тестом нужно в первую очередь проверять гипотезу реализации и тд.
Воспринимаете ли вы ошибки начинающего технического директора, как просчеты старшего товарища или как некомпетентность руководителя?
Оценка сугубо субъективная, все зависит от того, какую роль CTO играет в том, над чем ты работаешь: вряд ли ты будешь относиться как к старшему товарищу к мистеру «подай да принеси»; напротив, когда у тебя сформировано ощущение, что CTO — тоже участник процесса и польза, которую он привносит непосредственно в твой производственный процесс — осязаема, и, что немаловажно, ты, как технический сотрудник, ощущаешь что в «этом джедае больше силы» — то проникаешься к такому руководителю уважением и начинаешь воспринимать ваши неудачи — как общие. Есть, правда, риск повестись на обложку, а потом сильно обломаться — тогда это опыт в собственную копилку умения читать людей.
Сможет /должна ли команда «воспитывать/выращивать» технического директора? Какие случаи можете вспомнить?
Скорее нет, чем да. Но сделать его сильнее, может только команда.
Виктор Rpsl Диктор. Человек-оркестр.
Всем привет, в первую очередь я бы хотел сделать акцент на том, что наш мир многогранен, и нельзя делать поспешных выводов об ошибках или некомпетентности руководителей. Если вы занимаете разные должности, то и «колокольни» у вас разные, и вид с них открывается соответствующий. Зачастую те упущения, которые кажутся просчетом в данный момент, могут быть полезны в долгосрочной перспективе или диктоваться бизнесом.
Насколько часто начинающий технический директор ошибается с дедлайнами? Какие случаи можете вспомнить? Насколько это важно для вас?
Я не могу припомнить историй, когда бы технический директор сильно ошибался со сроками исполнения задач. У любого начальника есть хороший опыт на позициях разработчика, и он прекрасно знает, как нужно решать задачи, какие инструменты применять и сколько на это может уйти времени. Обычно, если задача ставится с четкими сроками, то тех.дир. всегда сам закладывает «буфер» времени, плюс согласует выполнение задачи с исполнителем. Подобный подход всегда обеспечивает выполнение задач в оговоренные сроки, если задача вещественна, а не «исследовательского» плана.
Насколько часто начинающий технический директор ошибается с постановкой и распределением задач среди сотрудников? Какие случаи можете вспомнить? Насколько это важно для вас?
Если говорить о распределении задач по сотрудникам, то тут ошибки происходят гораздо чаще. Очень часто я видел, когда задачи распределялись по принципу «ты этим уже занимался, ты это быстрее сделаешь». Опять же, ошибка это или нет можно долго дискутировать, но в долгосрочной перспективе это выливается в то, что у команды теряется понимание системы и все становятся специалистами в своем узком профиле, не умея работать с остальными компонентами системы.
В своей работе я предпочитаю перетасовывать задачи между исполнителями и стараться, чтобы не было людей, которые считаются «feature owner», такой подход позволяет всем быть в курсе всего, иметь многогранный взгляд на различные компоненты, да и атмосфера в коллективе улучшается.
Какие специалисты больше страдают от ошибок технического директора? Тестировщики, разработчики, проект-менеджеры? Какие случаи можете вспомнить? Насколько это важно для вас?
От ошибок руководителей больше всего страдают его подчиненные, ведь именно им приходится разгребать то, что произошло. Это касается как обещаний по срокам, так и выбора неправильных инструментов или подходов. Важно не путать это с ситуациями, когда выбранное решение подходило, а потом появились новые требования. Это нормальная ситуация, это работа, которую нужно делать, а не ошибки планирования.
Из своей практики у меня в памяти всплывает только один момент которому уже много лет, я помню, как уговаривал своего технического директора поменять стандарты и перейти на git с svn и на idea с netbeans. Все мои попытки разбивались о стену непонимания и утверждения, что «эти инструменты не дают ничего нового, абсолютно то же самое можно делать в текущих, а значит, в смене платформ нет смысла».
Воспринимаете ли вы ошибки начинающего технического директора, как просчеты старшего товарища или как некомпетентность руководителя?
Личное восприятие ошибок других – это весьма субъективная штука, она зависит от людей, между которыми проходит это процесс, и их взаимоотношений. Одни будут радоваться неудачам, другие сопереживать.
Сможет /должна ли команда «воспитывать/выращивать» технического директора? Какие случаи можете вспомнить?
Команда абсолютно точно должна воспитывать своего начальника, как и начальник должен воспитывать своих подчиненных. Не бывает в жизни здоровых отношений, в которых одним есть дело, а другим нет. Я не хочу сильно углубляться в поведенческие факторы, но любой начальник, технический директор это или тимлид, должен быть своеобразной «мамой гусыней» для своих подчиненных.
Необязательно быть с каждым лучшим другом, но очень важно не отбиваться от команды и всегда общаться с людьми, как со всеми вместе, так и с каждым с глазу на глаз.
Помню, когда я первый раз был тимлидом, я взял за правило минимум раз в месяц ходить на обед с каждым из подчиненных, чтобы у нас была возможность поговорить по душам. Я мог рассказать о процессах, которые происходят в компании и что планируется в ближайшее время, а ребята могли обсудить со мной те вещи, которые они не хотят озвучивать при всех или в чатах. На эту тему есть много книг, например «Как пасти котов», в них это все описано гораздо лучше, чем я могу изложить.
Спасибо за внимание.
P.S.
Надеемся, высказывания экспертов натолкнули кого-то на интересные выводы. Кто-то, возможно, узнал в их историях себя, а кто-то убедился в том, что все делает правильно. В любом случае, успех или провал проектов определяется не количеством ошибок технических директоров, а конечным результатом общей работы. С этой точки зрения, «непогрешимость» CTO выглядит второстепенным фактором.
Автор: semen_grinshtein
