Типові помилки починаючого технічного директора в ІТ — думки експертів


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

Від деяких співробітників ІТ-компаній досі можна почути таку репліку: «Я не зовсім розумію точне значення посади Технічний директор». відзначив в гранично простій формі один з користувачів «Тостера», «CTO — технічний людина, яка щось розуміє в бізнесі». Якщо розглядати це поняття трохи ширше, то можна сказати, що він балансує на стику між розробкою ІТ-продуктів з командою технічних фахівців і прийняттям бізнес-рішень спільно з менеджерами.

Відповідно, для фахівців, що бажають зайняти позицію технічного директора ІТ, , як мінімум два шляхи:

  1. стандартний — «Developer -> Senior -> Team lead -> CTO»;
  2. гуманітарний – «PM -> Senior PM -> CTO».
Безумовно, у разі другого варіанта розуміти технічні нюанси технічному директорові може бути складніше.

Але досягнувши бажаного, в цілому, досвідчений фахівець як би переходить в розряд початківців. Він стає отаким Junior-CTO і стикається з новими викликами.

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

Віктор Шабуров, підприємець, інвестор і один із засновників компаній 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 виглядає другорядним фактором.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.