Типичные ошибки начинающего технического директора в ИТ — мнения экспертов


    Изображение с сайта tech.co

    От некоторых сотрудников ИТ-компаний до сих пор можно услышать такую реплику: «Я не совсем понимаю точное значение должности Технический директор». Как отметил в предельно простой форме один из пользователей «Тостера», «CTO — технический человек, который что-то понимает в бизнесе». Если рассматривать это понятие чуть шире, то можно сказать, что он балансирует на стыке между разработкой ИТ-продуктов с командой технических специалистов и принятием бизнес-решений совместно с менеджерами.

    Соответственно, для специалистов, желающих занять позицию технического директора в ИТ, существует, как минимум два пути:

    1. стандартный — «Developer -> Senior -> Team lead -> CTO»;
    2. гуманитарный – «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 выглядит второстепенным фактором.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 25

      +2
      Техдир что ли заявки назначает? :)
      У меня до техдира 3 начальника есть. :)
        +8
        Хорошая статься, только непонятно почему вместо PM везде написано CTO. И почему он может быть выращен только аж из Senior PM. И где в этой картине мира Architect.
          0
          То есть уровень юниор для ТехДиректора звучит забавно, поэтому заменили на Developer (стандартный) и PM (гуманитарный) соответственно. Сам терин гуманитарный ТехДиректор это что то. :-)
            +2
            Был у нас «тех директор» с высшим медицинским образованием. Очень любил ходить и спрашивать: «Ребята, где дебаг? Где дебаг, ребят?»
              0
              https://www.youtube.com/watch?v=RGZwOoUy_HE
              +1
              А что в этом такого? Работа технического директора(уловите здесь слово ДИРЕКТОР) связана с гумунитарными областями знаний не меньше, чем с техническими.
              +3
              Изложенное применимо для стартапов, где всё техническое в немалой степени держится на одном человеке. Там CTO и Architect, и PM, и TeamLead, и SysAdmin и даже тестер при необходимости.

              В крупной же компании дела обстоят совершенно иначе. Всё же изначально был CIO, позже добавилась подчинённая более «гиковская» роль CTO — ответственного за технологии, а не за управление проектами. Для этого есть свой отдельный PMO, где требуется и экономическая образованность.

              В этой связке CIO по сути должен планировать верхнии уровни пирамиды архитектуры предприятия (бизнес, информация и процессы на высоком уровне), CTO уже вступает на средних в роли со-архитектора предприятия (информационные системы и выбор технологий), программные архитекторы уже работают в более прикладном нижнем уровне, и только потом дело доходит до разработчиков, сисадминов, QA и т.д. PMO организует работу исходя из бюджета, сроков и приоритетов. Я уже не вписывают сюда кучу других существенных ролей и отделов, область которых прямо не затронута в статье. Хотя тот же QA бывает совершенно обособленным отделом для объективности и несгибаемости перед PMO.

              Чисто по мне, «технический директор» совершенно неправильный термин. Если написать «главный инженер», то всё встаёт на свои места.
                +1
                завидую кейсам из статьи, где сроки можно умножать на два.
                Часто в жизни вопрос по срокам нового проекта ставится так:
                Founder: За сколько сделаете? Надо за 3 месяца максимум
                CTO: Я посчитал, тут работы на 4 минимум
                Founder: Надо за 3 месяца
                CTO: ок
                  +1
                  Junior-CTO

                  Пять баллов :)
                    +11
                    Почему в успешных кейсах руководители часто гордятся работой команды в праздники и выходные, разве это не провал планирования?
                      +1
                      Потому что больше нечем.
                        0
                        Такие же «эффективные менеджеры» просили меня сделать тестовое задание под Новый Год отняв у меня половину новогодних каникул.
                        К сожалению, я не приверженец лозунга «code eat sleep repeat»
                          +1
                          Вообще говоря, в праздники\выходные запускать может быть проще. Меньше юзеров, а значит меньше проблем в случае ошибок. У нас в компании иногда просят работать на выходных, за доп плату либо отгул.
                            0
                            По идее за 1 проработанный день в выходные или праздники справедливо просить 2 отгула.
                              0
                              Справедливость сильно зависит от ситуации.
                              • Для семейных людей удвоение оправдано, ибо работа в выходные — десинхронизация с близкими.
                              • Иногда я сам прошу дополнительный день (например, в следующую среду нужно смотаться на концерт) — тогда удвоенный отгул просить некомильфо.
                              • Иногда мне нужен отгул «прям щас» (в больничку с женой съездить, или просто абсолютно нерабочее настроение) — при таком раскладе справедливо один день отдохнуть, на выходных один день поработать.
                              • Иногда начальник сильно связан инструкциями сверху, и даже за обычную замену расписания может получить головомойку. Требовать два отгула в такой ситуации бесполезно, и приходится решать: либо работаешь за один, либо не меняешь расписание вообще.
                              • А иногда справедливо остаться на выходные вообще без отгулов — из-за собственного косяка.

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

                                  По идее, мои варианты не противоречат ТК (кроме последнего пункта). Но обратите внимание: я указал несколько случаев, когда работа на выходных инициируется работником, это исключительно его желание; работник не требует сверхурочных, а просит изменить его расписание. Подпадает ли такая ситуация под 152 статью ТК? Опять-таки, лично я работаю за границей России, и её ТК в моих отношениях с работодателем — не аргумент.
                                  Наконец, справедливость != законность. Законы — штука нужная, но не справедливая. Хотя кое в чем ТК справедлив:
                                  Конкретные размеры оплаты за сверхурочную работу могут определяться… трудовым договором.

                                  Именно это указано комментарием выше:
                                  такие вещи лучше всего обговаривать при устройстве на работу
                                    0
                                    Да я не то чтобы спорю, это же лежит в плоскости Ваших отношений с работодателем. Я тоже работаю не в РФ, но получаю 2ную ставку за сверхурочные, что, как помне, намного лучше чем 1.5x и, тем более 1x. Так почему бы не вбросить кому-то идею, что «так тоже можно» :D Мало ли Вы не знали
                                  0
                                  Если Вы сами его соблюдаете, само собой)
                            +2
                            Я лично покинул бы с поднятым средним пальцем, проект, где меня «успешный и эффективный junior CTO на пятом курсе института» попросил бы работать на выходных или праздниках. Пусть работает с такими же успешными и эффективным студентами сокурсниками.
                              +4
                              во-во.
                              меня пару дней назад соискатель при приеме на работу спрашивал: «а как с переработками дела обстоят?»
                              Я озвучил свою логику, что сроки часто горят, но отработав 40 часов в неделю, человек всегда свободен, т.к. если где-то не успеваем, то значит я неправильно произвел расчет, или распределил нагрузку, или не проконтролировал чей-то ступор. Так что в любом случае это моя проблема, работники — это просто ресурс.
                                0
                                Откуда столь категорично-негативное восприятие студентов пятикурсников?
                                Меня в свое время нанимал президент по технологиям с последнего года аспирантуры. До аспирантуры он лет 10 поработал в IT безопасности.
                                Один из моих студентов третье-курсников владел собственной фирмой по Web-разработке.
                                На одном из соседних потоков в моем университете учился дядечка, было ему 50 лет. 30 лет из них он проработал на одном закрытом предприятии, специализирующимся на лазерах, в том числе на руководящих должностях.

                                Что касается «попросил бы работать на выходных или праздниках» — а что в этом такого, при наличии компенсации? Вы так трепетно относитесь к дню России и дню народного единства?
                                  +1
                                  Негативное отношение не к студентам-пятикурсникам(я, например вообще без ВО), а студентам-пятикурсникам, просящим работать по выходным и праздникам, при этом гордящимся этим. Очевидно, что если команда вынуждена работать тогда, когда работать не должна менеджмент допускает серьезные ошибки и гордиться тут, мягко говоря не чем. А они при этом считают себя успешными CTO. Другой вопрос еще в том, что по моему скромному мнению, для того, что бы быть CTO нужен опыт в IT более серьезный, чем у среднего лида, или PM, а тот студнет-пятикурсник о котором идет речь в статье просто в силу своего возраста, с высокой вероятностью не обладает таким опытом.

                                  Вот я сейчас работаю CTO. И мне 23 года. И я буду искать себе более опытную замену как только появится такая возможность. И уж тем более я не называю себя успешным CTO. И никогда не гордился тем, что несколько раз приходилось заставлять людей работать в праздники. Хотя делаю я это только в том случае, если с оставшимися задачами я сам не в состоянии справится за время праздников\выходных при условии, что в экстренных ситуациях я работаю 18 часов в сутки. Да, у нас пока маленький стартап, но вопрос же скорее в отношении.
                                    –1
                                    Время редактирования истекло, удалить не дают. Как же неудобно…
                                    0
                                    Негативное отношение не к студентам-пятикурсникам(я, например вообще без ВО), а студентам-пятикурсникам, просящим работать по выходным и праздникам, при этом гордящимся этим. Очевидно, что если команда вынуждена работать тогда, когда работать не должна, менеджмент допускает серьезные ошибки и гордиться тут, мягко говоря, не чем. А они при этом считают себя успешными CTO. Другой вопрос еще в том, что по моему скромному мнению, для того, что бы быть CTO нужен опыт в IT намного более серьезный, чем у среднего лида, или PM, а тот студнет-пятикурсник о котором идет речь в статье просто в силу своего возраста, с высокой вероятностью не обладает таким опытом.

                                    Вот я сейчас работаю CTO(хотя считаю эти три буквы в моем конкретном случае простым словоблудием. Просто никто более опытный чем я не согласился на такие условия. Хотя, судя по HH.ru в РФ и таких условий обычно нет). И мне 23 года. При этом у меня есть опыт работы старшим и ведущим разработчиком в крупных IT-компаниях.

                                    И я буду искать себе более опытную замену как только появится такая возможность. И уж тем более я не называю себя успешным CTO. И никогда не гордился тем, что несколько раз приходилось заставлять людей работать в праздники. Хотя делаю я это только в том случае, если с оставшимися задачами я сам не в состоянии справится за время праздников\выходных при условии, что в экстренных ситуациях я работаю 18 часов в сутки. Да, у нас пока маленький стартап, но вопрос же скорее в отношении.

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое