Comments 11
Брать на себя важные таски, когда есть много других активностей (встречи, «синки») — верный путь потерять все полимеры.
Я для себя сделал вывод, что нужно учиться доверять ответственность команде. Да, они сделают задачу медленнее, чем «я в вакуууме». Но проблема в том, что вакуума нет, вокруг воздух и другие активности, которые отвлекают лида. Поэтому задача либо не будет сделана, либо будет сделана в выходные. Что является путём в выгорание.
В таких компаниях надо противиться такой политике. Ну, или менять компанию, если изменить ничего нельзя
Григорий Остер добрался до IT
Хотя на 2-м пункте закрались сомнения. Только на 5-м пункте понял, что это стёб).
Надо бы добавить тег "сарказм" :)
Вот по поводу п.3, часто разрабы сами упираются и не ходят никуда идти, ибо "теряем время". В принципе с п.5 почти аналогично. "Какая конференция, когда я ещё свою супер фичу не закончил?"
По поводу пункта 8.
А что делать, если в результате работы человека (или даже группы) вышло что-то нерасширяемое и трудно поддерживаемое? Вот прям недавно человек в команде выдал решение, где в масштабируемом микросервисе использовал sqlite. Я очень удивился, начал расспрашивать, почему так. Выяснилось, что он sqlite собирался использовать как очередь (при том, что у нас есть PubSub). Периодически должна была запускаться команда, которая бы обрабатывала записи из базы. Кроме того он запланировал простой микросервис удаления данных по gdpr превратить в почему-то систему по управлению newsletter'ами. А ещё человек не следовал практикам, которые были ранее обговорены. Как быть? Особенно в условиях, когда задача была спущен инвестором и требовалось её сделать "ещё вчера".
Понять, что к такому привело:
Хорошо ли была поставлена задача?
Было ли промежуточное код-ревью? (Или классический MR на +10000 строк в 1 коммит в конце)
Были ли донесены до команды/человека сроки?
Что говорила команда/человек на дейликах (если они были)?
Ну, то есть можно сразу приступать к сжиганию ведьм (исполнитель нехороший и любит овер-инжиниринг), но лучше исходить из презумпции невиновности :)
Хорошо ли была поставлена задача?
С точки зрения бизнеса — да. Но обсуждения, как реализовывать, не было.
Было ли промежуточное код-ревью?
Ну, там ревью заняло 10 минут от силы. Объем таков был, что промежуточный был ни к чему (хотя он по сути и оказался промежуточным).
Были ли донесены до команды/человека сроки?
Да.
Что говорила команда/человек на дейликах (если они были)?
"Делаю, скоро представлю результат". Речь шла о том, что данный функционал нужен был в легаси. На счет качества в легаси мы весьма терпимы, поэтому вопросов не возникло. А в результате — внезапно — появился новый проект (апи для использования из легаси).
Проблема возникла, как по мне, по следующим причинам:
- отсутствие качественной коммуникации внутри команды;
- попытка взять на себя ответственность за задачу человеком с недостаточным уровнем компетенции при планировании архитектуры;
- ложное понимание требований к скорости реализации задачи (а именно быстро — не значит, что создать новый набор проблем);
- чисто программистский подход (мол, у меня локально работает, а как оно там будет в продакшне работать, это пусть чешутся ребята из SRE).
В данном случае я бы ожидал, что человек прежде, чем к чему-то приступать, все-таки обсудил бы с командой. К сожалению, он это обсудил только с одним членом команды (оба они сейчас проходят процедуру повышения квалификации). Вместе они приняли решение, которое не устроило бы ни нашего VP of Engineering, ни SRE по вполне объективным причинам. Как результат решение было в режиме Pair Programming полностью переделано.
С точки зрения бизнеса — да. Но обсуждения, как реализовывать, не было.
ИМХО это и есть ключевая проблема - нужно было обсуждать реализацию раз задача сложная и важная. Либо отдать это на откуп техлиду. Но он должен быть компетентен и быть в курсе где и что использовать.
10 практик «ответственного» тимлида