Комментарии 30
>С очень высоким техническим уровнем.
>не умел декомпозировать задачи
Извините, но не верю. Декомпозиция задач — это часть именно технического уровня. То кто не умеет это делать — не умеет и планировать, потому что без декомпозиции оценки времени становятся отфонарными. Вот не верю я, что его технический уровень высок.
>не умел декомпозировать задачи
Извините, но не верю. Декомпозиция задач — это часть именно технического уровня. То кто не умеет это делать — не умеет и планировать, потому что без декомпозиции оценки времени становятся отфонарными. Вот не верю я, что его технический уровень высок.
Я бы сказал что декомпозиция это сочетание технического понимания решаемой задачи, адекватности оценки возможностей членов команды, степень доверия своим сотрудникам и способность оценить риски.
А уровень лида был высок с точки зрения фундаментальной подготовки и владения техстеком, насколько я понял.
Давайте я уточню: на мой взгляд декомпозиция — это чуть ли не основное для того, чтобы решать сложные задачи.
Разбиение сложной задачи на простые, потом выполнение их по частям, и получение результата в целом — это все вполне осмысленно вообще без упоминания про сотрудников, команды и т.п., и применимо даже если вы работаете один. Поэтому я и не считаю это частью задач руководителя. Ну или не только руководителя. Высококвалифицированный программист должен это делать, и делает ежедневно.
Если человек такое не умеет, он возможно и высокой квалификации специалист, но он вряд ли разработчик. Ну то есть, например — теоретик, но сделать что-либо руками зачастую неспособен. А уж для техлида это просто странное свойство.
Разбиение сложной задачи на простые, потом выполнение их по частям, и получение результата в целом — это все вполне осмысленно вообще без упоминания про сотрудников, команды и т.п., и применимо даже если вы работаете один. Поэтому я и не считаю это частью задач руководителя. Ну или не только руководителя. Высококвалифицированный программист должен это делать, и делает ежедневно.
Если человек такое не умеет, он возможно и высокой квалификации специалист, но он вряд ли разработчик. Ну то есть, например — теоретик, но сделать что-либо руками зачастую неспособен. А уж для техлида это просто странное свойство.
Это просто типичный пример принципа Питера.
Корреляция между «цветом штанов» и способностью создавать качественное ПО обычно нет.
Корреляция между «цветом штанов» и способностью создавать качественное ПО обычно нет.
Вполне может такое быть. Сам таким был. Декомпозиция задачи по ходу её решения — работающий подход при индивидуальной или почти индивидуальной разработке (один или два очень сильных по меркам команды, остальные на подхвате). Понимаешь, что упустил что-то — делаешь заглушку и или делегируешь джуну, или откладываешь на потом. Планирование, да, почти невозможно со слов менеджера "не меньше недели, но вряд ли больше двух месяцев, при условии, что других задач не будет" — мало их устраивает. Но это работающий подход.
Рулить командой — это не технический скилл.
У меня был позитивный опыт когда в команде на одного мидла было два синьора. В команде процветал троллинг как и у героя статьи. Но это мужской коллектив и я не знаю как может быть иначе.
На ревью у нашего мидла порой набиралось по паре десятков коммитов. Психологически процесс для парня был довольно жестким, но и скорость роста фантастическая. За три года он прошел путь от стажера до крепкого мидла, который может уже претендовать на синьора и ни на кого обиды не держит.
Но когда собираемся тем самым коллективом пива попить — он всё равно «стажер».
На ревью у нашего мидла порой набиралось по паре десятков коммитов. Психологически процесс для парня был довольно жестким, но и скорость роста фантастическая. За три года он прошел путь от стажера до крепкого мидла, который может уже претендовать на синьора и ни на кого обиды не держит.
Но когда собираемся тем самым коллективом пива попить — он всё равно «стажер».
Умеют же некоторые разводить на ровном месте стены текста, вместо простых ответов.
Итак, выявляем проблему:
Раз:
Два:
Причина у этого одна, и называется она — спешка. Все вот эти вот «быстрей-быстрей, дедлайны горят!»
Решается она через приучение руководства планировать. Горят сроки? — Учитесь планировать.
И еще нужно учитывать существование определенного типажа руководителя — «всегда мало». Такой руководитель будет недоволен всегда — сделали проект за год — медленно, надо было за пол года. Сделали за полгода — медленно, надо было за месяц. Сделали за месяц — медленно, надо было за неделю. И т.д.
Состав команды, их реальная скорость разработки не играет никакой роли. Программистов всегда будут торопить, ставить неадекватные дедлайны, и ругать.
Таких руководителей надо уметь быстро выявлять и прощаться с ними.
И дальше идет какая-то стена воды…
Джуны нужны в двух случаях:
1. Есть много рутинной работы
2. Способ проверки ИТ отдела. Если после появления джуна, в проекте стало больше багов и говнокода, а тимлид на это отвечает «ну это все новый джун» — значит, процесс разработки выстроен неправильно. В нормальном процессе, с ревью кода, с тестами, с CI/CD «система» не позволит плохому коду попасть в продакшен.
Итак, выявляем проблему:
Раз:
скорость работы миддла не удовлетворяла руководство, хотя качество его кода было высоким.
Два:
приводило к перманентному перенапряжению всех разработчиков.
Причина у этого одна, и называется она — спешка. Все вот эти вот «быстрей-быстрей, дедлайны горят!»
Решается она через приучение руководства планировать. Горят сроки? — Учитесь планировать.
И еще нужно учитывать существование определенного типажа руководителя — «всегда мало». Такой руководитель будет недоволен всегда — сделали проект за год — медленно, надо было за пол года. Сделали за полгода — медленно, надо было за месяц. Сделали за месяц — медленно, надо было за неделю. И т.д.
Состав команды, их реальная скорость разработки не играет никакой роли. Программистов всегда будут торопить, ставить неадекватные дедлайны, и ругать.
Таких руководителей надо уметь быстро выявлять и прощаться с ними.
Почему каждой компании нужны младшие разработчики
И дальше идет какая-то стена воды…
Джуны нужны в двух случаях:
1. Есть много рутинной работы
2. Способ проверки ИТ отдела. Если после появления джуна, в проекте стало больше багов и говнокода, а тимлид на это отвечает «ну это все новый джун» — значит, процесс разработки выстроен неправильно. В нормальном процессе, с ревью кода, с тестами, с CI/CD «система» не позволит плохому коду попасть в продакшен.
Любая работа рутинная, если ты ее делал уже несколько раз. Поэтому первый пункт применим практически к любой команде. Что касается второго, то наличие джунов в команде предъявляет другие требования ещё и к старшим разработчикам, а не только к процессам.
Решается она через приучение руководства планировать. Горят сроки? — Учитесь планировать.
Как только оценки сложности и длительности задач начнут совпадать с реальностью, так сразу планы начнут выполнятся. А пока на критическом пути проекта будут попадаться задачи, время выполнения которых внезапно меняются в 10 раз, будут авралы, «быстрей-быстрей» и прочее. Такова жизнь.
Имхо, когда каждая или каждая вторая задача аврал — это не норма.
Менеджер, осуществляющий планирование, обязан закладывать резервы, коэффициенты, ещё что-то, а не просто составить график из оценок разработчиков.
Если он знает, что у 10% задач сроки стабильно увеличиваются в 10 раз, то планировать надо, грубо говоря, умножая оценку на 2.
Найдите мне менеджера, который не умножает на 2 или на Пи :) Но менеджер не знает у какого процента и насколько растет срок. Причина в том, что часто растет не срок задачи, а задача порождает другие задачи. «Сделали», а потом долго долго чиним. Или «сделали»,
показали заказчику и пошли доделывать и так 20 раз по кругу, каждый круг — новые задачи на доработку старой. Как правило в трекере никто не проставляет явные зависимости, что вот эта задача породила вот эту.
В итоге достаточно легко можно сказать, что суммарно планировали сделать за X, а сделали за Y. А какой % задач провалился и насколько, сказать тяжело, для этого надо в ручном режиме анализировать весь ход проекта и все взаимосвязи между задачами. Это сделать сложно, но вполне возможно. И даже тогда, благие намерения разбиваются о следующую проблему.
Разные комбинации команды, предметной области, решаемой задачи и заказчика имеют тенденцию порождать разное количество доработок и багов. Чаще всего в каждом новом проекте хоть что-то из перечисленного меняется достаточно сильно.
В итоге нормальное планирование возможно когда одна и та же команда делает раз за разом одно и то же. Например пилит интернет магазины в одной и той же области или клепает 100500 форм в очередной ERP. Такое бывает и там, как правило, авралов нет.
показали заказчику и пошли доделывать и так 20 раз по кругу, каждый круг — новые задачи на доработку старой. Как правило в трекере никто не проставляет явные зависимости, что вот эта задача породила вот эту.
В итоге достаточно легко можно сказать, что суммарно планировали сделать за X, а сделали за Y. А какой % задач провалился и насколько, сказать тяжело, для этого надо в ручном режиме анализировать весь ход проекта и все взаимосвязи между задачами. Это сделать сложно, но вполне возможно. И даже тогда, благие намерения разбиваются о следующую проблему.
Разные комбинации команды, предметной области, решаемой задачи и заказчика имеют тенденцию порождать разное количество доработок и багов. Чаще всего в каждом новом проекте хоть что-то из перечисленного меняется достаточно сильно.
В итоге нормальное планирование возможно когда одна и та же команда делает раз за разом одно и то же. Например пилит интернет магазины в одной и той же области или клепает 100500 форм в очередной ERP. Такое бывает и там, как правило, авралов нет.
У нас вот сейчас висит очередь из задач, по которым отдел разработки не успевает, и нас подгоняют. Но если вглядеться — одна задача ждёт согласования с пиар отделом уже третью неделю, другую сделали и протестировали — но помимо технической интеграции надо заключить договор и согласовать юридические моменты, и вот уже неделю задача не может дойти до прода, хотя кричали «нужно срочно!». Ещё несколько задач по интеграции с другими продуктами компании — ждут реализации и документации от команд этих других продуктов. И вот получается странная картина — вроде как техотдел затягивает сроки и не закрывает задачи — а вроде как и делать нечего, и мы сидим и занимаемся закрытием технического долга и рефакторингом.
Я как старый бюрократ, рекомендую вам провести подготовку к претензионной работе:
для начала написать письмо на тех, кто вас держит, с копией вашему продакту, а если он факапщик, то копию тому лицу, которое имеет право назначать виноватых.
Содержание примерно следующее:
Коллеги привет!
Графиком разработки сервиса Х, утвержденным (договор, протокол совещания, ид карточки в СЭДО и т.п.), предусмотрена выдача его в тестирование 01.06.2020г.
Уведомляем вас, что в соответствии с указанным графиком, сервис передан на тестирование 25.05.2020г. и успешно прошел все этапы, что подтверждается Заключением о прохождении тестирования №1 от 30.05.2020г.
Для передачи сервиса в деплой на промышленный стенд, требуется х1, х2, х3.
Выполнение данных активностей в соответствии с действующей матрицей распределения обязанностей находится в ответственности у1, у2 (отделы).
На данный момент нас не уведомили о выполнении указанных активностей, что не позволяет выполнить деплой сервиса на промышленный стенд.
Прошу вас сообщить сроки выполнения указанных активностей.
для начала написать письмо на тех, кто вас держит, с копией вашему продакту, а если он факапщик, то копию тому лицу, которое имеет право назначать виноватых.
Содержание примерно следующее:
Коллеги привет!
Графиком разработки сервиса Х, утвержденным (договор, протокол совещания, ид карточки в СЭДО и т.п.), предусмотрена выдача его в тестирование 01.06.2020г.
Уведомляем вас, что в соответствии с указанным графиком, сервис передан на тестирование 25.05.2020г. и успешно прошел все этапы, что подтверждается Заключением о прохождении тестирования №1 от 30.05.2020г.
Для передачи сервиса в деплой на промышленный стенд, требуется х1, х2, х3.
Выполнение данных активностей в соответствии с действующей матрицей распределения обязанностей находится в ответственности у1, у2 (отделы).
На данный момент нас не уведомили о выполнении указанных активностей, что не позволяет выполнить деплой сервиса на промышленный стенд.
Прошу вас сообщить сроки выполнения указанных активностей.
отсутствие техлида. Формально техлид был. С очень высоким техническим уровнем. Но как руководитель, который мог заниматься ведением и развитием своей группы, он был полный ноль: не умел декомпозировать задачи, распределять их в соответствии с уровнем каждого члена, не занимался обучением группы, контроль деятельности группы осуществлялся в диктаторском режиме, софт скиллы отсутствовали и т.п.
Из всего перечисленного для техлида половина звучит как плюсы.
Беда в общем, какая-то, или с переводом, или с компанией исходного автора.
Техлид и не должен заниматься декомпозицией задач и разделять их на людей — его ответственность осуществлять надзор за качеством системы, делать самые технически сложные таски, и т.п.
А тут как-то роли тимлида и техлида смешаны. Они могут, конечно, пересекаться в одном человеке, но это разные роли с разными требуемыми качествами.
Обучение (техническое) скорее входит в обязанности техлида, чем нет.
я поэтому и написал, что половина.
Вообще, статья начинается с описания ситуации, в которой возникла проблема, но не рассказывается, из-за чего возникла ситуация.
У меня большие вопросы к
Зачем мидл в команде 6ти сеньоров?
Я знаю ровно 2 кейса когда собирают такую команду.
1) Делаем что-то очень сложное и мидл нужен, чтобы на него скинуть рутину.
Тогда глупо предъявлять сеньорам, что они не не учат мидла — его не для того нанимали.
2) Делаем что-то очень сложное и мидл должен дотянуться до уровня сеньоров —
тогда глупо жаловаться на
потому что дотянуться до уровня сеньоров нужно тебе — ты и впахивай, учись задавать правильные вопросы, чтобы отвлекать более опытных товарищей на максимально короткое время.
В остальном статья уходит в «хорошо быть богатым и здоровым, чем бедным и больным»
Вообще, статья начинается с описания ситуации, в которой возникла проблема, но не рассказывается, из-за чего возникла ситуация.
У меня большие вопросы к
из команды разработки, которая состояла из 6-ти сеньоров и одного миддла
Зачем мидл в команде 6ти сеньоров?
Я знаю ровно 2 кейса когда собирают такую команду.
1) Делаем что-то очень сложное и мидл нужен, чтобы на него скинуть рутину.
Тогда глупо предъявлять сеньорам, что они не не учат мидла — его не для того нанимали.
2) Делаем что-то очень сложное и мидл должен дотянуться до уровня сеньоров —
тогда глупо жаловаться на
То, что было непонятно миддлу, приходилось изучать на 95% самостоятельно, потому что у сеньоров не было времени и желания помогать миддлу в обучении, отсутствовало парное программирование (при этом код-ревью было отличным с технической точки зрения), в результате скорость работы миддла не удовлетворяла руководство, хотя качество его кода было высоким.
потому что дотянуться до уровня сеньоров нужно тебе — ты и впахивай, учись задавать правильные вопросы, чтобы отвлекать более опытных товарищей на максимально короткое время.
В остальном статья уходит в «хорошо быть богатым и здоровым, чем бедным и больным»
Вы сеньор сейчас?
Как это относится к обсуждаемому вопросу?
Если вам так интересен уровень собеседника — я регулярно выполняю задачи senior уровня, но не могу быть уверен в своих знаниях (с моей точки зрения, они всегда недостаточно глубоки) + не самый широкий стек.
Поскольку понятия о senior-уровне довольно размытое, я не готов утверждать о своём гарантией.
А так — новичков обучал, системы проектировал, бизнес/технические требования собирал и описывал.
Если вам так интересен уровень собеседника — я регулярно выполняю задачи senior уровня, но не могу быть уверен в своих знаниях (с моей точки зрения, они всегда недостаточно глубоки) + не самый широкий стек.
Поскольку понятия о senior-уровне довольно размытое, я не готов утверждать о своём гарантией.
А так — новичков обучал, системы проектировал, бизнес/технические требования собирал и описывал.
Спасибо за ответ. Я спросил вот почему: миддлы и сеньеры по разному смотрят на процесс обучения (по моим наблюдениям). Часть сеньоров считают, что миддлы должны обучаться полностью самостоятельно, как выживание в Спарте: не утонул в водоеме — сильный, будешь жить. Более того есть миддлы которые смогли развиться в рамках такого подхода. Но обучение нужно для того чтобы сжато и системно передать те знания которые накапливались десятилетиями. Да, можно самостоятельно их изучить, но либо это будет недопустимо долго для бизнеса, либо с недопустимо низким качеством, либо ученик гений и тогда он за приемлемый срок самостоятельно поднимет свой уровень до достаточного.
Э-э-э вообще то преподавать тоже надо уметь. И многие просто этого не умеют. Так что обучение это все таки проблема обучающегося. Хороший учитель не сможет обучить, того кто не хочет и сопротивляется обучению. А вот хороший ученик может научиться и у плохого учителя.
Если бизнесу надо кого-то обучить, то пусть отправляет на обучение.
Если хотите чтобы обучали тимлиды, то научите их учить.
Если бизнесу надо кого-то обучить, то пусть отправляет на обучение.
Если хотите чтобы обучали тимлиды, то научите их учить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Базовое руководство по созданию сбалансированных команд разработчиков