Comments 17
Хорошая статья, спасибо.
В завершение части про коммуникации повторюсь, любая неопределенность — это сигнал для вас как тимлида, будьте любопытны к ним. Это не значит быть затычкой в каждой бочке. Просто уделите внимание ситуациям, когда кто-то что-то недоговаривает, кому-то некомфортно. Подобная чуткость позволит вам построить продуктивные, дружелюбные и открытые отношения.
Тут важно не перегибать. Был у меня как-то руководитель, на одной работе, такой "папа" по складу характера. Ему надо было всех постоянно опекать и наставлять. Я только начал работать, и он решил что просто обязан помочь мне влиться в коллектив, постоянно прикладывал к этому усилия, отчего я постоянно оказывался в каких-то неловких ситуациях, и период адаптации в этом самом коллективе у меня сильно затянулся, что еще больше подталкивало руководителя к стремлению мне помочь.
Иногда, КМК, стоит все-же дать людям самим как-то все утрясти, без "медвежьей помощи", вмешиваться только если есть уже какая-то явная проблема.
Абсолютно согласен. Коллег не нужно "спасать" - вокруг люди взрослые и умные, сами все умеют. Смысл совета в том, чтобы подтолкнуть к открытому разговору того, кто видит проблему, но, например, стесняется ее обозначить. То есть просто "сделать первый шаг".
Но если запроса на твою помощь нет - просто устранись. И искать проблемы там, где их нет, конечно, тоже не стоит.
Поэтому в случае пожаров вместо «финансового» подхода стоит действовать в соответствии с этикой пластической хирургии:
Только минимальные, чуть видимые изменения
Это когда "исходник" и так уже довольно неплох. Ну там линию губ слегка поправили, или нос сделали ровнее.. А если у пациента все лицо - сплошной рубец от ожога? Как тут отделаться "минимальными, чуть видимыми" изменениями?
Уже работал на нескольких проектах с такими вот "ожогами", как правило там тоже всегда пытались починить все понемногу, и как правило все это стремление тонуло в рутине, и незавершенный рефакторинг делал код зачастую еще более дурнопахнущим.
Мне кажется, мы с вами пишем об одной и той же проблеме.
"пытались починить все понемногу" - это как раз распыление, от которого я предостерегаю. За один раз надо решать одну проблему, но решать ее качественно, в идеале до конца.
"незавершенный рефакторинг делал код зачастую еще более дурнопахнущим" - а это как раз недовернутый цикл Деминга. Не закончили, отвлеклись, и вот у нас +1 долг.
Или я что-то неверно понял из вашего комментария?
В целом да, об одной и той-же. Я просто обратил внимание на то, что бывают ситуации ,в которых не отделаешься маленькими шажками с минимальными изменениями. Бывают рефакторинги, когда надо или переделать сразу очень много, или вовсе за них не браться. Скажем код большого и важного модуля окончательно протух и косметический ремонт там уже не поможет, его надо полностью переписать. При этом переписывание полностью, по факту, блокирует внедрение новых фич. Если все-же пытаться, под давлением бизнеса , допиливать фичи одновременно с рефакторингом, то чаще всего получается что рефакторинг отменяют, или того хуже - бросают недоделанным на пол пути, из-за чего получившийся код станет еще хуже, чем до попытки "ремонта".
Т.е. все-же бывают (и нередко) ситуации, при которых желательно на какое-то время заморозить работу над фичами и полностью сосредоточится на техдолге.
Довольная частая ситуация у начинающего тимлида — наваливается столько задач, что наступает паника.
Самое плохое, что может случиться для проекта - это начинающий тимлид. А все остальное - это семечки.
Это скорее не плохое, а просто имеющаяся реальность.
Никто не хочет лечиться у неопытного врача, отдавать ребенка неопытному преподавателю, нанимать на атомную станцию неопытного физика-ядерщика :)
Но, чтобы у нас были опытные специалисты, им нужно где-то получать опыт. Поэтому важно делиться своими знаниями с теми, кому они нужны, и оказывать поддержку новичкам. Другого пути я не вижу.
Лучше тимлида выращивать когда он не на должности, а в подчинении опытного тимлида
Лучше дать будущему тимлиду в подчинение одного падавана - джуна или мидла. Если через пару месяцев производительность такой мини-команды окажется хороша - значит можно еще добавлять падаванов, попробовать добавить сеньора, более старшего коллегу(по возрасту) и так выкуется полноценный тимлид. Кстати, многие тимлиды совсем не умеют работать с равными по скиллам или превосходящими, а также с более возрастными коллегами. И научиться этому весьма непросто.
Справедливости ради, врач перед первой самостоятельной операцией обязан предупредить пациента, а пациент вправе отказаться от операции и дождаться более опытного врача.
На мой взгляд статья как-то быстро переходит к плану действий, а ведь самый главный вопрос, на мой взгляд, который должен задать себе любой человек на «горящем» проекте — почему я оказался на горящем проекте?
Или, вопрос можно сформулировать еще более конкретней:
Почему я, добросовестно отрабатывая свои 40 часов в неделю испытываю стресс, чувство долга и чувство, что я кого-то подвел?
Выводы, к которым я пришел за свою рабочую практику такие:
Оказался на горящем проекте (здесь же проекты с вечно горящими сроками, с вечной суетой и неадекватным руководством) — не распознал бракованную компанию на уровне собеседования. Следовательно, на следующих собеседованиях нужно задавать больше вопросов про переработки, горящие сроки и не работать в подобных компаниях.
Если честно отрабатывая свои 40 часов, вы испытываете чувство дискомфорта и стресса — значит кто-то сел вам на шею. Классический вариант: руководство хочет побыстрее, и давит на программистов. Вывод, следующий: еще на уровне собеседовании озвучиваете, что вы против переработок, что у вас есть своя личная жизнь, и убивать её ради работы не собираетесь. Также я отдельно пишу в резюме, что не стрессоустойчивый, чтобы потом не удивлялись, что из-за психологического давления я могу сорваться на крик. И никакого угрызения совести у меня не будет — нечего садиться на шею.
Если же говорить об уровне тим-лида, то здесь все эти вопросы (почему вы оказались в неадекватной компании, почему вам сели на шею) должны звучать еще острее — все же опыта у тим-лида должно быть больше, чем у рядового разработчика.
И еще, прежде чем что-то делать — стоит задать себе вопрос: а оно мне надо? Когда на рынке острая нехватка специалистов, стоит ли работать в компаниях, которые не умеют выстраивать адекватные бизнес процессы?
Конечно, разок в жизни можно вытащить проект из «огня», просто доказав себе, что можешь. Но с точки зрения практики это не имеет никакого смысла — здоровье, которое часто убивается на этом пути, потом ни за какие деньги уже не купишь. Это говорю как человек, который только за последний год потратил на врачей ~700 тысяч.
Яростно плюсую, что на таких ситуациях можно здоровье потерять - у самого такой опыт есть. Но вот на вопрос:
Почему я, добросовестно отрабатывая свои 40 часов в неделю испытываю стресс, чувство долга и чувство, что я кого-то подвел?
Я решил менять не компании, а свое отношение к стрессу. Потому что видел руководителей, основателей стартапов и собственников бизнеса у которых нагрузка гораздо выше моей, но они почему-то не сгорали.
Вместо того, чтобы искать компанию с хорошими процессами, можно научиться их создавать. И я постепенно понял, что стрессоустойчивость это не про то, кто крепче всех сжал челюсти и пашет. Это про умение не вовлекаться в проблему лично, но спокойно и методично выстраивать те самые бизнес-процессы и культуру работы в компании.
Ведь хорошие бизнес-процессы и культура в компаниях сами собой не появляются. Их создают сотрудники, и в том числе тимлиды. И моя статья это опыт создания таких процессов и культуры. Все здесь описанное, это вместо 80-часовой недели и стресса, а не вдобавок к ним.
Получается, всех этих петель обратной связи у нас нет. Мы доставляем новый функционал до прода вслепую, с минимумом проверок. И сейчас наша задача создать всего одну петлю обратной связи. Но самую эффективную и самую дешевую. Какой из вариантов петли выбрать? В данном случае мы возьмем юнит тесты, потому что из всех проблем они левее всех в цепочке поставки. Это вообще неплохой ориентир при принятии решений
Но лучше начинать всё-таки с CI, а не с тестов.
Потому что покрытие тестами всего кода — задача глобальная, а CI зачастую можно за день (с большим запасом) сделать и забыть. А ещё потому что сборка вручную задалбывает, особенно когда просят срочно собрать проект, а у тебя локальные изменения в нём. Опять же, тесты без CI — хрень, просто потому что их будут забывать запускать.
Здесь наверно как всегда с точностью до смысла, который вкладывается в понятия.
Я так понял, что CI нужна уже совсем правильная, не просто сборка, а с автотестированием и всеми остальными контролями и настройками. А юнит тесты может гонять программер, перед тем как сделать коммит, для проверки себя любимого. И в этом случае оправдано чуть-чуть покрыть кода, чтобы понимать на самом раннем этапе (только напечатано) где ломается при добавлении функциональсти.
Закалка тимлида: как вывести проект из пожара, не сгореть самому и не спалить команду