В прошлой статье я упоминал о четырёх уровнях осознанности техдира. Приведу эти 4 этапа, пройденные мной лично, ниже:
Ответственность за программирование;
Ответственность за технологическую часть продажи;
Ответственность не только за тех. процессы (аналитика, тестирование, менеджмент – на выбор)
Ответственность за полный цикл производства продукта, удерживая в фокусе внимания все связанные с производством процессы.
Следовательно мы видим перед собой картину, как юный технический директор растет в профессиональном плане. Происходит избавлении от различных проявлений неврастении в виде IT-фашизма или управленческой импотенции. Приходит осознание проф. обязанностей и зоны ответственности за цикл производства. Голова раскалывается и наступает жесткое интеллектуальное похмелье, а состояние лучше все визуализирует мемная картинка ниже.
Это очень сложный период. Количество вопросов растет, а ответы найти становится все сложнее. Подростковая IT-фантастика, вроде некогда популярной когда-то книги “Deadline” Тома ДеМарко может навредить, а Максима Дорофеева читать рановато. Вопросы, мучающие разум нашего техдира, намного проще и конкретнее. Например: “Какие у технического директора должностные инструкции и обязанности в зоне ответственности за полный производственный цикл? У всех они есть, а где же тогда мои? Обидно как-то…” Поэтому именно данную тему, хотелось бы затронуть сегодня.
Примечание автора:
Под должностными обязанностями я имею в виду их содержательную часть, а не форму. Если вы подходите к своему программисту, возомнившему себя специалистом широкого профиля и говорите что-то вроде “Вася, на фронтенд больше не лезь! Ты там 5 минут поработал – вся контора уже неделю чинит!” - то в этот момент вы очертили его должностные обязанности. И тут главное, чтобы он вас послушал. А нужна ли для этого специальная бумага в отделе кадров зависит от многих факторов.
Должностные обязанности
Главная проблема должностных обязанностей технического директора связана с тем, что как только ты пытаешься их струтурировать и внятно представить в виде текста, в результате обязательно получится непригодная ни к чему туалетная бумажка.
Вот попытка от украинских коллег: https://dou.ua/lenta/articles/cto-position/:
Определение общих стратегий технического развития;
Принятие глобальных технических решений;
Внутренний технический арбитраж;
Выбор технологий, которые будут использоваться в том или ином проекте;
Оценка этих технологий в плане финансовых и временных затрат;
Оценка длительности и трудоемкости проектов;
Планирование и построение процессов разработки;
Формирование команд разработчиков;
Распределение задач между командами;
Отслеживание продвижения проектов;
Обеспечение темпа и качество разработки на максимально высоком уровне;
Выбор и внедрение вспомогательных систем для разработки и администрации;
Экспертные предложения по архитектуре или конкретным техническим решениям;
Написание кода, обзоры кода, рефакторинг;
Технический pre-sale ключевых проектов;
Управление техническими рисками на проектах;
Общение с другими отделами и топ-менеджерами компании (CEO, COO, CIO и др.);
Координация работы департаментов;
Технические собеседования с новыми сотрудниками;
Оценка продуктивности сотрудников и решение об уровне их зарплат;
Обучение сотрудников;
Формирование рабочей атмосферы в коллективе, мотивация сотрудников;
Разборы полетов с тимлидами
Попытка конечно хорошая, но многовато для одного человека. Или выполнение всего перечня не обязательно? И что же конкретно должен выполнять наш техдир в рамках пунктов, описанных ниже?
Определение общих стратегий технического развития
Принятие глобальных технических решений
Обеспечение темпа и качество разработки на максимально высоком уровне
Общение с другими отделами и топ-менеджерами компании?
По моему личному мнению, из списка только эти два пункта можно строго отнести к должности техдира (заменив при этом слово “общение” на слово “координация”) . Остальным можно и нужно заниматься при условии отсутствия данных специалистов.
Вывод: данный вариант – шляпа. Для отдела кадров сойдёт, конечно, но толку от такой должностной инструкции нет, потому что она ничего конкретно не объясняет. Непонятно какого конечного результата вы должны достигнуть, делая всё это. Так что если вы работаете в крупной корпорации или вам не важен результат по любой другой причине – на этом чтение статьи можете заканчивать и нести в отдел кадров полученный список :)
С остальными же продолжаем!
В другую крайность впадать тоже нельзя. Решить, что я теперь “отвечаю за всё” – прямой путь к выгоранию. Никто и никогда не сможет отвечать вообще за все, в том числе и техдир. Надо понимать, что сами по себе должностные инструкции не очень хорошо работают даже для линейных сотрудников. Есть такой термин – Итальянская забастовка. Суть ее в том, что сотрудники начинают эти самые инструкции исполнять до запятой. Эффект получается, как от ядерной бомбы. Однако есть одно НО, линейный сотрудник может себе позволит создавать иллюзию бурной деятельности до момента пока его не уволят, а техдир нет.
Я нашёл для себя следующее решение. Я определяю для себя три вещи:
Конечный продукт – то, за что я получаю зарплату (именно продукт).
Зоны ответственности – те вещи, без которых конечный продукт не получится и за которые я могу отвечать (пример: производственный процесс).
Фокус внимания – те вещи, без которых конечный продукт не получится, но я не могу за них отвечать напрямую (пример: стоимость техники).
При этом чем больше вы сможете из фокуса внимания переместить в зону ответственности – тем больше ваша система будет управляема. Главное не надорвитесь.
Итак, конечный продукт технического директора, который я определил для себя, выглядит следующим образом:
Себестоимость производства конечного продукта компании должна быть ниже, чем у прямых конкурентов производящих продукт того же качества.
И так, сразу отвечу на пару потенциальных вопросов.
1. Почему ниже? Пусть будет равна или даже несколько больше, всё равно ещё есть конечная стоимость, маркетинг, продажники – сбыть наш продукт их проблема.
Я действительно знаю конторы, где тащит хороший маркетинг и продажи при высокой себестоимости производства по вине техдира. Ну что тут скажешь – продажники молодцы, а техдир – нет. Можно ли быть стрёмным техдиром и получать зарплату? Можно, но зачем?
2. Почему только прямые конкуренты?
Если вы онлайн-кинотеатр, то как будете сравнивать производительность со своим косвенным конкурентом – кинотеатром обычным? Впрочем косвенных надо держать в поле зрения и помнить о них, это правда.
3. Почему себестоимость? Я технарь, я не хочу разбираться в деньгах.
Можно не разбираться, но понимать про них должен. Иначе – вон из профессии в тимлиды или даже разработчики. Потому что на уровне директора – вы оперируете деньгами и завязаны на них. Простой пример: тимлид может не задумываться при выборе стека технологий о средней стоимости разработчика на рынке. Техдир же обязан об этом думать.
Зоны ответственности
С конечным продуктом разобрались.
Теперь зоны ответственности:
-
Производственный процесс:
Техническая часть производственного процесса (архитектура, стэк-технологий, инструменты, информационная безопасность).
Организационная часть производственного процесса (орг. структура, должностные инструкции, техники менеджмента).
Кадры, здесь зоны ответственности технического директора в том:
чем люди работают;
как люди работают;
какие люди работают.
А вот что он делает в рамках реализации своей ответственности – зависит от конкретной ситуации. К примеру, если ваша компания состоит из 15 человек, и вы нанимаете по 2-3 человека в год, вы действительно собеседуете их лично. И этого может быть достаточно. Когда у вас 60 человек, то вы должны работать с HR’ом и тимлидами, передавая им свой опыт, своё виденье, выстраивая процессы и настраивая работу. Если у вас более 100 человек, тогда уже тимлиды и HR будут транслировать своё видение и опыт вам. Главное своевременно задать нужный вектор данного процесса
Тоже самое с производственным процессом. До 30 человек – я спокойно принимал все основные технические решение самостоятельно. Теперь у меня сидит целый отдел “ядерной” (от слова “ядро”) разработки.
Поговорим ещё о фокусе внимания. Что я держал в нём:
Клиентов;
Конкурентов (прямых и косвенных);
Всё, что касается технологических/организационных вопросов в моей сфере;
Уровень специалистов на рынке труда и их зарплаты;
Уровень подготовки в учебных учреждениях города.
И еще ряд специфических моментов, про которые вам неинтересно.)
Главный вопрос во всем этом деле – если мы ничего не можем напрямую с этим поделать, зачем нам про это знать? Реально, отдельная компания ведь не способна в одиночку повлиять на уровень подготовки студентов?
Или способна?)
То, что мы не можем за отвечать за данный процесс, не означает, что мы не можем влиять. К примеру, я несколько лет выступал экспертом WorldSkills по специальности “Дизайн и разработка”. Не знаю про средний уровень по городу - но то, что эта деятельность повлияла на программу подготовки нескольких техникумов – могу сказать точно.
Самое главное, что мы можем хотя бы частично переводить вещи из фокуса внимания в зону ответственности. Ярким примером является проект Smart Академия. Еще во время работы техдиром в компании “Умный мир”, я понял, что нам не подходят в достаточном количестве ни люди с рынка, ни выпускники учебных учреждений – нам пришлось взять процесс ввода в специальность в свои руки. Кстати, если кто-то на этом моменте пожелает плюнуть в ВУЗы или СУЗы, остановитесь. Дело в первую очередь не в качестве образования, а в том, что между получением образования и освоением профессии есть определенная разница. Там, где сохранился адекватный подход к стажировкам с вводом в специальность, всё более или менее нормально. А вот в Российском IT он не то что сохраниться, он выработаться не успел)))
Должны ли мы, как малые предприниматели, решать эту глобальную проблему? Нет, не должны. Но без этого, мы не решили бы свои задачи по росту, потому что 53 человека из 100 в компании – это выпускники Академии. А значит не надо ныть о падении образования, как это делают некоторые коллеги, а что-то придумывать. Вот мы и придумали – и сегодня Smart Академия самый мощный проект в Томске по вводу в IT.
Теперь, уже как директор компании Спутник – я иду дальше. Моя команда готова транслировать опыт коллегам. Я уверен, что в ближайшее время, вы увидите много толковых стажировочных программ от самых лучших компаний и проектов Томска.
Таким образом образуется супер крутой кейс. Решая собственную проблему, мы создаем новый сектор бизнеса.
Резюмируем
Определите ваш конечный продукт.
Определите за что вы должны отвечать, чтобы он получился (зоны ответственности).
Определите, какие внешние факторы на него влияют (фокус внимания).
Должностные обязанности – это то, что вам нужно делать, чтобы нести ответственность прямо здесь и прямо сейчас.
Со временем конечный продукт остается неизменным и может быть пересмотрен только в связи с какими-то фундаментальными изменениями. Зоны ответственности и фокус внимания – это рабочий инструмент, с которым вы системно работаете в рамках понимания конечного продукта.
А вот что вы делаете в рамках этих зон, то есть ваши должностные обязанности, зависит от многих факторов, например, таких как рост компании. То есть вы их должны регулярно пересматривать! Чтобы не оказалось случайно, что вы лично собеседуете всех 100 сотрудников компании. Вы тогда HR, а не техдир :)
И, конечно же, ищите мощные ходы, чтобы снизить влияние внешних факторов на вашу деятельность.
Кстати, приём с конечным продуктом хорош не только для директоров. Рекомендую проделать его со всеми работниками и внести конечный продукт в должностную инструкцию. В каком бы виде она у вас не существовала :)
Подписывайтесь на мой инстаграм, это тоже один из новых вызовов. Как минимум, буду публиковать там анонсы новых статей.
Комментарии (4)
Grigorenkovic
03.08.2021 21:51В теории список хорош, но на практике...
Определение общих стратегий технического развития - Стратегии определены, но по факту не используются;
Принятие глобальных технических решений - решения используются, но не по назначению :)
Внутренний технический арбитраж - практикуется, но нет результата, или есть побочные эффекты;
Выбор технологий, которые будут использоваться в том или ином проекте - технологии выбраны, но они постоянно меняются;
Оценка этих технологий в плане финансовых и временных затрат - для оценки использованы неактуальные и не наиболее приоритетные показатели;
Оценка длительности и трудоемкости проектов - размыта;
Планирование и построение процессов разработки - осуществляется без связи с требованиями бизнеса;
Формирование команд разработчиков - случайное распределение, которое подкреплено ничем не подтвержденными аргументами;
Распределение задач между командами - как всегда неоптимальное;
Отслеживание продвижения проектов - на 99% завершены;
Обеспечение темпа и качество разработки на максимально высоком уровне - есть релизы и тестирование, темп и качество соблюдаются благодаря множеству незначительных и не очень нужных доработок;
Выбор и внедрение вспомогательных систем для разработки и администрации - постоянное улучшение, изменение и замена этих систем;
Экспертные предложения по архитектуре или конкретным техническим решениям - старания предложить решения best practices, которые по отзывам работают, но не у вас;
Написание кода, обзоры кода, рефакторинг - поиск причин почему выбранный для ревью код неоптимален;
Технический pre-sale ключевых проектов - недостаточно опыта для проведения пресейлов;
Управление техническими рисками на проектах - воспоминания о прошлых фейлах;
Общение с другими отделами и топ-менеджерами компании (CEO, COO, CIO и др.) - стремление выглядеть на уровне;
Координация работы департаментов - безуспешные (не всегда) попытки угодить всем;
Технические собеседования с новыми сотрудниками - показательное превосходство;
Оценка продуктивности сотрудников и решение об уровне их зарплат - принимаются спонтанно;
Обучение сотрудников - с минимальными финансовыми затратами и максимальными требованиями отдачи;
Формирование рабочей атмосферы в коллективе, мотивация сотрудников - поиск точек соприкосновения (не так уж и плохо);
Разборы полетов с тимлидами - попытки понять кто неправ и переложить ответственность;
Katunov
Если в компании для определения должностных обязанностей требуется проводить целое исследование (возникают проблемы с их четким и понятным определением), то может ей просто не нужен "технический директор"?
mpudalov Автор
Проблемы с понимаем должностных обязанностей, возникают не у компании, а у самого техдира. Обычно если проблем у техдира не возникает, то одно из двух:
Техдир имеет большой опыт и прекрасно знает что должен делать.
Техдир или компания так и не вышли из стадии "техдир - это такой самый сильный программист в конторе"