Comments 7
Ох, ваш пост прям как бальзам на рану, как раз прохожу через многие круги этого маленького локального ада под названием «Превращение из разработчика в технического менеджера», и, порой, невольно сбиваешься на панику) Спасибо!
Спасибо, прочитал с удовольствием. Многое не ново, но повторение полезно.
Хотел бы высказать по следующему моменту:
«Думайте о том, как сделать правильно изначально, а не как потом исправить. „
Здесь соглашусь лишь частично, т.к. моя практика, увы, показывает, что не редко бывает “лучше сделать 2 раза вовремя, чем 1 раз правильно» (эту фразу услышал когда-то от своего руководителя). Поэтому, не стоит всегда стараться сразу сделать «правильно» — оценивайте ситуацию, а не тупо следуйте «правилам».
Хотел бы высказать по следующему моменту:
«Думайте о том, как сделать правильно изначально, а не как потом исправить. „
Здесь соглашусь лишь частично, т.к. моя практика, увы, показывает, что не редко бывает “лучше сделать 2 раза вовремя, чем 1 раз правильно» (эту фразу услышал когда-то от своего руководителя). Поэтому, не стоит всегда стараться сразу сделать «правильно» — оценивайте ситуацию, а не тупо следуйте «правилам».
По-моему, автор статьи пытается одновременно быть архитектором, team leader и project manager’ом.
Не соглашусь, project manager находится на вершине конечного продукта, а продукт может состоять из нескольких компонентов, у каждого компонента свой team leader.
Сам был в такой ситуации когда являюсь team leader со стороны программистов и в соседнем кабинете team leader от электронщиков, а в сумме реализовали один программно-аппаратный проект и менеджер у нас был один. А потом добавился team leader по внедрению и сопровождению. Который нам через менеджера передавал желаемые нововведения.
Чем крупнее проект и чем больше разработчиков тем тяжелее одному становится контролировать всё, поэтому схема может удлиняться до:
В таком подходе Технический директор формирует команды для выполнения определённого модуля и передает часть своих полномочий Руководителю группы. По достижению результата группа или распускается или ей выдается новый модуль. Часто при выдаче нового модуля без роспуска группы производится изменение Руководителя группы на другого её члена, в основном по принципу знания основной технологии но и самое главное от готовности Руководителя группы брать на себя ответственность.
Сам был в такой ситуации когда являюсь team leader со стороны программистов и в соседнем кабинете team leader от электронщиков, а в сумме реализовали один программно-аппаратный проект и менеджер у нас был один. А потом добавился team leader по внедрению и сопровождению. Который нам через менеджера передавал желаемые нововведения.
Чем крупнее проект и чем больше разработчиков тем тяжелее одному становится контролировать всё, поэтому схема может удлиняться до:
Технический директор -> Руководитель группы (он же - ведущий программист) -> РазработчикВ таком подходе Технический директор формирует команды для выполнения определённого модуля и передает часть своих полномочий Руководителю группы. По достижению результата группа или распускается или ей выдается новый модуль. Часто при выдаче нового модуля без роспуска группы производится изменение Руководителя группы на другого её члена, в основном по принципу знания основной технологии но и самое главное от готовности Руководителя группы брать на себя ответственность.
Прослезился от того, насколько верно написано.
Добавлю 5-ый пункт в план по поиску решения:
Если решение не очевидно или интуиция подсказывает, что вы придумали «не красивого монстра, которого мы потом отрефакторим» — то не надо боятся показаться некомпетентным, а стоит открыто вынести проблему на обсуждение с командой, друзьями (причем иногда бывает полезнее обратится не к профильными IT-шникам, а к технически грамотным людям из других сфер — они еще не испорчены шаблонами, платформами, фреймворками). Во-первых вы получите другие точки зрения, во-вторых разделите ответственность за выбор. И самое главное — пока вы будете объяснять кому-то суть проблемы и доказывать свое решение — скорее всего вы сами сделаете верный выбор.
Добавлю 5-ый пункт в план по поиску решения:
Если решение не очевидно или интуиция подсказывает, что вы придумали «не красивого монстра, которого мы потом отрефакторим» — то не надо боятся показаться некомпетентным, а стоит открыто вынести проблему на обсуждение с командой, друзьями (причем иногда бывает полезнее обратится не к профильными IT-шникам, а к технически грамотным людям из других сфер — они еще не испорчены шаблонами, платформами, фреймворками). Во-первых вы получите другие точки зрения, во-вторых разделите ответственность за выбор. И самое главное — пока вы будете объяснять кому-то суть проблемы и доказывать свое решение — скорее всего вы сами сделаете верный выбор.
Как правило, он не управляет людьми, а вместо этого учит их наилучшим образом выполнять свою работу
В статье большой упор на технологии, но все же Технический директор работает в первую очередь с людьми и уровень вербальной коммуникабельности очень важен (по крайней мере для России).
Кроме кода Технический директор оценивает и людей, влияет на улучшение не только профессиональных навыков но и личностных качеств — ответственность, коммуникабельность, умение выражать мысли,… список огромен. Но это не значит обломать всех под единый стандарт Если есть замкнутый человек создающий прекрасный код по предоставленному ТЗ или устному заданию и ему комфортно в замкнутости то попытка его вовлечь в командный дух чревата потерей качественного разработчика.
Sign up to leave a comment.
Эффективное техническое руководство