Комментарии 41
Давным давно я работал тех лидом. В те времена тоже были джуны, мидлы и сениоры. Я раздавал задачи, делал код ревью, помогал, отвечал на вопросы. Я мог делегировать задачу, даже джуну, обозначив рамками место, куда он должен интегрировать свой код с прописанным контрактом.
Сейчас на мне формально нет лидерских обязанностей, но волей не волей приходится взаимодействовать с людьми. И современные реали и для меня стали совсем другими. Возможно это из-за смены поколения, возможно из-за вкатышей таксистов/курьеров/поваров. Но эти люди
Пишут код и приходят с вопросом почему у них там эксепшен - они сами не собираются тратить свои силы и время раскапывать то, что они там сами понаписали
Не способны к обучению - они раз за разом натыкаются на те же грабли, каждый раз приходят за помощью по одним и тем же вопросам - и даже я, кто не делает их задач, помню, что они уже напарывались на такое или уже решали эту задачу, а они этого не помнят!
Не способны коммуницировать - только на третий возврат задачи из тестирования по поводу блокирующей баги этот человек говорит, что она у него не воспроизводится.
Когда они говорят что сделали, но на самом деле ничего не сделали
Отсутствие элементарного логического мышления у программиста! Абстрактное мышление для них вообще высший класс
Они не могут за один раз пометить поля на форме обязательными с валидацией. Как будто они впервые видят интернет, формы логина и пароля и никогда этим не пользовались.
Все что описано в статье - у меня работало в те далекие времена. Сейчас же, в обозначенных выше кейсах - действительно лучше таких уволить и все сделать самому.
Слишком много моего времени уходит на такое «менторство», на микроменеджмент, чтобы не допустить всякой очевидной для меня дичи.
Джуны и мидлы в давние времена - были взрослыми людьми. Современные джуны, мидлы, и те, кто идентифицирует себя сениорами - мамкины детишки.
Я нашёл Вас! Тех, кто после курсов с Яндекса взял этих поваров на работу. Блин это как единорога увидеть)) Открою пива баночку)
В статье меня это порадовало: "Техзадание: «Сделать авторизацию на сайте»". И что это плохо.
Блин ребята. Сейчас все тех задания такие - они на словах, они от РП вообще прилетают. И Ваша задача, о ужас - пойти и самим из РП вытрясти инфу, что ему там надо вообще по итогу. Почему самим? Ну вы как минимум взрослый человек. А если не получилось - тут то и подключается тимлид, пойти кому сопли вытирать конфетку дать, кому леща отвесить, кому дипломатически объяснить ценность диалога РП-исполнитель.
Вобщем и правда свод правил вроде полезный. Но как будто уже нужен новый)
Ну сейчас ИИ эпоха. И кодер, которому нужна разжёванная постановка до последней детальки - ну пойдет в жпт чат вобъёт её - получит код и будет чилить. И о ужас такие кодеры-чилибасеры несамостоятельные заменятся на ИИ первыми. Если их уже не меняют - я удивлён.
Все совпадения случайны 😅
Сейчас все тех задания такие - они на словах
Это не тех. задание. А бизнес хотелка. С ней по хорошему должен разбираться аналитик.
Если у вас в команде скипают аналитику и разрабу приходится трясти заказчика чё он ваще хочет - это хреново. Как это потом тестировать? Где источник истины? Разрабу на слово поверить что так надо было? Или тоже идти продукта трясти?
А может он изначально хотел херню и не нашлось аналитика, который ему в красках и цифрах опишет что фича не имеет ценности, формы и стоить будет неопределённо долго.
РП и Аналитик иногда одно и тоже. Не особо они переводят потребности бизнеса на системный язык. Лично мне иногда проще самому с заказчиком поговорить и объяснить ему, что модель данных которую он предложил нуждается в корректировках.
Я уже 100 лет в обед не видел ТЗ. В котором не знаю указан фреймворк или база данных какую надо взять. Или даже язык программирования. Просто написано в ТЗ - сделать раздел такой-то, там пусть будет вот это вота. И это прям ТЗ от заказчика.
Пиннаешь РП/Аналитика - иди мол узнай вот эта вота это что? Он приходит - ну оно такое вот ну это красное. Говоришь - устрой встречу с заказчиком - давайте вместе пообщаемся. А там оказывается не десктоп приложение а хайлоад система с кучей железа. И цвет не важен.
На 5+ наверное выстроенна инфраструктура только в биг техах. Там наверное пишут в ТЗ вот вам кусок кода, вставьте - запустите. Хз.
"Как это потом тестировать?"
Как же я буду тестировать модель данных с кучей фишек, которую сам создал со слов заказчика и перепродал назад - я даже хз. Наверное мне очень тяжело будет тестами покрыть систему собою же и сотворенную. Или нет.
Айти оно разное короче. Где то разработчики просто думают как написать код чтобы байтики покрутить в оперативке. А где-то разработчики думают зачем вообще они пишут, что они пишут. Где-то погоня за RPS, а где-то оно никому не сдалось. Где-то перед разработчиком и заказчиком цепочка из 10 человек. А где-то дай бог один и не дай бог один на один. Где-то разработчики сами ещё инфраструктуру собирают на бар металле и cicd своих же сервисов делают.
На 5+ наверное выстроенна инфраструктура только в биг техах. Там наверное пишут в ТЗ вот вам кусок кода, вставьте - запустите. Хз.
В биг техах достаточно богаты, чтобы не разделять на разработчиков и аналитиков. Задача ставится так что «надо добавить вот это вот в нашу легаси систему», дальше «бойцовый кот есть боевая единица сама в себе».
В статье меня это порадовало: "Техзадание: «Сделать авторизацию на сайте»". И что это плохо.
А что в этом хорошего?) ТЗ/спецификации должны содержать все информацию, для того чтобы разработчик мог успешно выполнить задачу и ее потом протестировали. Я не поддерживаю подход, когда в тикете написано "Нужно сделать авторизацию. Инфу дам на созвоне". Как в таком случае потом пройдет тестировании задачи? "Оперативная память" человека не настолько велика, чтобы все нюансы запомнить на созвоне. А когда все перед глазами, то и тимлид/техлид смогут сразу сказать, что есть нюансы в этой фиче, разработчик четко выполнит задачу с первого раза (баги не считаем) и тп.
Ну сейчас ИИ эпоха. И кодер, которому нужна разжёванная постановка до последней детальки - ну пойдет в жпт чат вобъёт её - получит код и будет чилить
Не спорю, ИИ упрощает работу и может дать базу. Но вот качество такого кода под вопросом... Потом мы удивляемся, почему с ИБ все плохо, с архитектурой проекта все плохо и тп и тд
Так не надо запоминать - надо записывать. И писать протоколы совещаний/созвонов.
И писать протоколы совещаний/созвонов.
Нет, не надо. Для этого уже придуман специальный документ — ТЗ. Там должно быть исчерпывающее описание задачи, исполнитель и срок.
А распылять инфу по куче документов это не только нелогично, но и непродуктивно.
И последнее. Что не все тимлиды понимают. ТЗ — это юридический документ.
Например, у нас в компании мы не делаем свыше того, что есть в ТЗ. А если ПМ потом такой: «ой, я забыл(а), надо ещё одну фичу добавить», то это а) озвучивается на общем митинге, б) официально создаётся новая задача с новыми сроками. И все вопросы «а почему дедлайн съехал» автоматически отправляются к виновнику.
Потому что бывает, что за срыв дедлайна наказывают. А я не люблю быть наказан, если я не виноват.
Вот тут и приходит на помощь ТЗ.
Согласен. Я всегда за то, чтобы на берегу определить ожидаемый результат и оформить все в виду документа - ТЗ.
ТЗ хоть в каком-то виде обязательно - это абсолютно верно. Но ТЗ бывают разные. Некоторые - невнятные, некоторые - допускающие вариативность исполнения, некоторые - нереализуемые.
Чтобы это донести до автора задачи, надо списаться/созвониться. И запротоколировать содеянное (в т.ч. с помощью распознавалок речи). Изменения в ТЗ тоже должны быть записаны/запротоколированы. Что будет потом: сдвинется ли срок или будет назначена новая задача - вопрос организации работ.
Чтобы это донести до автора задачи, надо списаться/созвониться.
Нет, не надо.
1) В начале работы совместно вырабатывается единый формат ТЗ. Нужные поля, данные, цифры — неважно, как это будет выглядеть, главное, чтобы всех устраивало. Пока не выработаете, не начинаете работу.
2) Потом просто каждый делает свою часть: ПМ (или кто за это отвечает) заполняет ТЗ согласно темплейту.
3) Если чего-то нет, ему в личку (или сразу в общий чат, зависит от отношений) сбрасывается стандартная фраза типа «ТЗ не заполнен». После ПМ должен ответить «Готово». И так пока ТЗ не будет заполнен. Проблемные переписки скринятся и (желательно) отправляются в комменты таски. Чтобы потом не было вопросов.
4) Если процесс поставлен хорошо, и у всех с головой ОК, то п. 3 не возникает. Если возникает, надо бороться.
5) Если не можете продвинуться дальше пп. 1-2, я рекомендую идти к верхнему боссу и выяснять. Если результат будет 0, рекомендую сменить работу/проект, тут жизни не дадут.
А я вот сейчас работаю тех лидом. И являюсь узким горлышком, потому что ни один мр без моего полного погружения и разбора полетов не попадает в реп. И я хз как увеличивать компетенцию команды до достаточного уровня, потому что я и так требую, чтобы они ревьюили, но это не даёт результата.
Пытаться набрать людей,которым это тоже интересно. Смотреть гитхабы там перед тем собесами и прочее
Конечно, без полного контекста трудно что-то сказать.
Но я зацепился за слово "требую". Я очень редко что-то требую от своих ребят. Когда у нас появляется какая-то систематическая проблема, мы вместе ищем её решение.
Проблема с код ревью вообще частая, и у нас она тоже периодически возрождается
Могу порекомендовать крутой инструмент "5 почему". С его помощью можно попробовать добраться до сути.
Также хорошая практика - cross-ревью. Часто это "заходит" ребятам и они более ответственно подходят к ревью и написанию кода.
Возможно также, что в команде не хватает сильного человека, который сможет взять на себя ревью и разгрузить Вас.
А какое распределение джунов, мидлов и сеньеров в команде? Если еще есть сеньеры, то можете распределить ответственность с ними: они тоже ревьювят, для мерджа достаточно аппрува одного из вас, если кто-то систематически халатно это делает (каждый мердж критическте проблемы), то значит повод пообщаться
Да и присоединяясь к другим комментариям, некоторые ошибки должны выстрелить, чтобы разработчик понял, что так делать не надо. Что-то может найтись на QA, что-то при бегом ручном тестировании другого разраба. Я не говорю, конечно, о том, чтобы ломать прод. Но иногда новый тикет для разраба для фикса его бага действует очень весомо.
У нас ещё тот, кто делает ревью, тоже отвечает за эти изменения, и спрос будет с обоих.
К тому же, большие фичи смотрят сениоры, мелкие - можно делегировать миддлам. Плюс иногда подключать мида/джуна, чтобы посмотрел на то, как написан код, что исправлено итд, тоже, чтобы чему-то новому научиться.
По сути, задача тимлида - поставить проект на рельсы. В эту задачу также входит и развитие команды, в том числе научить их самостоятельности. "Само" ничего работать не будет)
Уже пора смириться с тем, что произошла смена поколений и на смену взрослым людям приходят выпускники ВУЗов и курсов. И с такими людьми можно успешно строить команду.
Далеко не все молодые разработчики таки. Многое зависит от подхода к их адаптации и обучению.
Давайте не будем путать и поддаваться.
Тим-лид - это не лидер проекта, это лидер команды: найм, онбоардинг, развитие навыков, решение конфликтов, и тому подобное. Он не кодит и не делает таски из жиры и несет ответственность перед дедлайном опосредованно.
Я крайне редко встречал правильные вакансии тим-лидов. Обычно компании экономят и обзывают людей, кто решил бы все их проблемы - тим лидами, тех лидами, ведущими и прочее. И вешают на них всех собак.
И я согласен с тем, что не все такие.
Так повелось, что я неформальной лидер. Формально я senior помидор. И бывает так, что руководитель мне даёт порулить каким нибудь проектом - просто потому что так проще. Ему это погружаться в контекст, раздавать задачи, выяснять все проблемы и приоритеты расставлять, потом с другими руководителями общаться... Да и других делов у него хватает.
А мне и в радость. Меня сам проект драйвит, мне нравится погружаться прям и вглубь и вширь, мне нравится встречаться с коллегами по проекту потому что они няшки, а ещё потому что у меня soft skills пресловутые прокачаны поболее, чем hard skills и поэтому я люблю заниматься этим всем...
И вот то, что я для себя вывел, какие золотые правила, которых я придерживаюсь и мне нравится как команда фигачит, всё делает чётко:
Юмор. Да, шутки прибаутки, но и какие-то милые приколы, которые могут приесться (за год не приелись). Например, я в конце говорю всем "всё, всех обнял приподнял". Или "ну что, всех можно обнимать и расходиться?" а мне добавляют "а как же приподнять?"
Неожиданные порывы нежности. Я просто в конце созвона говорю "блин какие ж вы все всё-таки красавчики, умные такие, я прям завидую, прям нравится с вами работать. Если б везде такие люди работали мы были бы лучшей страной"
Поскольку я формально не являюсь шефом, то я ещё напоминаю бывает, что "ребята, помните, мы - команда, я не ваш шеф и я в случае чего окажусь в таком же положении как и вы, поэтому давайте не допустим какую-то фатальную ошибку и если есть какие-то предложения, вопросы, претензии по тому же распределению задач, то можно и щас это сказать, когда я весь такой настроенный выслушать критику, а можно и в личку - туда всегда welcome и вообще лучше созвониться если что. Так что за всеми вопросами welcome и всё такое "
И конечно же опять из-за предыдущего пункта я рассказываю команде чем я займусь и на что это повлияет и всё такое. Крч перед ними как перед руководителями отчитываюсь.
Хз скорее всего не всё вспомнил, не всё применимо к тимлиду но я прям кайфую от работы с коллегами и все вроде тоже кайфуют
Это здорово, когда в команде поддерживается такая атмосфера! Видно, что у Вас доверие и взаимопонимание на высоком уровне)
Но у меня есть вопрос: если руководитель поручает Вам рулить проектом, значит, Вы уже не просто участник, а тот, кто несет ответственность за его успех. Бывало ли, что приходилось балансировать между поддержанием такой дружеской атмосферы и необходимостью быть более требовательным?
Быть более требовательным - конечно.
Пример. Я говорю другому разработчику - когда будем ставить merge request, то не мержим, как будто мы одни на проекте. Перед этим давай ставить друг друга в апруверы. И конечно он допускает ошибки логические. Указываю, рассказывая что ожидалось и что по факту получим благодаря коду. Рассказываю как исправить чтоб всем жилось весело, легко и задорно.
2 пример. Мне было некогда делать такой review кода, а задача, которую закрывал код, прям очень нужен был. Я просто апрувнул записав в голове "надо будет проверить". После релиза пошёл потыкал в интерфейсе сайта ту самую фигню. Увидел не критическую, но ошибку, которая если не закрыть сразу, то потом будет больно очень и трудно вспомнить "что вообще хотел сказать автор".
3 пример. Разработчики склонны делать вместо fix bugs - улучшайзинги. Типа места ещё много на диске, каждый backup весит 50 мб, но скапливается (не удаляются те что старше 30 дней). Хочется этим заняться вместо ошибки импорта данных. Приходилось перенаправлять разработчика говоря "это здорово но это пока нафиг никому не нужно и никто не оценит, а все ждут исправления бага. Пожалуйста, займись багой".
4 пример. Я не помню какие задачи закрыл другой разработчик, а список нужен для отчётности и всё такое. Очень прошу и бывает пинаю мол ну где там ну шо там, а то нам капец будет
Подскажи, пожалуйста, у тебя не бывает загонов что тебе за это не платят. Что ты так и будешь сидеть в разрабах и делать работу тимлида за свою ЗП?
Я понял о чем ты пишешь, но нет, загонов нет просто потому, что ситуация другая.
Мне нравится на позиции разработчика (не стремлюсь в тимлиды)
За неформальное лидерство (а по сути так оно и есть) не приплачивают никогда, поэтому и по деньгам я не в обиде
Мне нравится рулить проектом находясь на позиции разработчика
Вот если бы я стремился стать тимлидом или мне "втюхали" проект - тогда было бы обидно. А так... Я видел что никого нет из тех, кто мог бы рулить проектом, и я вызвался. Всё добровольно, все довольны.
Но кстати подумываю стать тимлидом (пока прям стремления нет, только мысли).
А у нас в "команде" РП - напрочь травмированный токсик и абьюзер, который даже с женой разговаривая по телефону, постоянно ее унижает и обесценивает. А начальничку хоть бы хны - он с ним корефанится. А потом этот же РП ему свои капризы предъявляет: мол, "если ещё раз мне заказчик скажет то-то и то-то, я пошлю его (читай - обижусь) и не буду заниматься этой работой". Другой коллега, главный конструктор, не знает ни основ ЕСКД, ни принципов конструирования, ни технологии обработки материалов, но самое главное - ему просто на всё пох, он сидит и буквально ничего из работы не делает, а если делает, то настолько похабно, что диву даёшься, ну и по взглядам его полностью понятно, что человек живёт по принципу безответственности. Другой конструктор - недоделанный студент, который буквально вообще ничего не знает и не умеет, но что более страшно - ничего не хочет знать и уметь, сидит целыми днями в телефоне чатится, его жизненный девиз - "Да мне как-то пох". Сколько я на него энергии и времени потратил, был негласным наставником, но оказалось, что его волнует только "а чё такая премия маленькая". Но при всем этом платят хорошо, премии хорошие, высшее руководство адекватное, закидонов с режимами и слежкой нет. А жаль, так бы взял да и ушел не задумываясь. Но работу свою очень люблю.
6 из 7 подойдут как базовые законы для любого управления. Любым процессом.
Не хватает кмк- тщательный отбор людей в команду. Гавноработники не должны пройти. Должны быть адекватные в разумных рамках преданные делу хороши в команде или для своей задачи. Они должны быть лучшими.
Знание пределов возможностей каждого члена команды. Дашь человеку непо сильную задачу а он постеснялся сказать я не знаю как. И приехали. И обратное - знать сильные стороны каждого. Есть задача со звездочкой. К ней есть Вася хитро умный. Есть простое но занудное и есть валя которая катит без ошибок
6 из 7 подойдут как базовые законы для любого управления.
Просто лид как правило не имеет никакого менеджерского образования. Повезёт если компания на курс какой отправит. А то и не повезёт. Лид вырастает из обычного работяги с врождёнными лидерскими задатками. Или даже без них если поставить было некого.
И эта база для того кто только вступил в должность неочевидна. Сам лидом не был, но довелось пройти через таких вот ребят, которые не следуют базовым вещам по неопытности.
Да и не все с опытом то им следуют...
С современным поколением разрабов этот список нужно дополнить пунктом
Будь готов объяснять почему ты хочешь чтобы он сделал именно так.
Потому что среднестатистическому зумеру пофиг сколько у тебя там лет опыта, он знает лучше если не доказано обратного. И с одной стороны это конечно не плохо, что они пытаются понять логику мышления опытного коллеги. Но когда они упираются рогом и говорят, что не будут менять код пока ты не объяснишь почему именно так. А потом ещё решают согласны ли они с твоими доводами или нет, то тут начинаются проблемы.
В общем за не умение "пояснить за базар" всегда могли быть проблемы
Это действительно существенная боль в текущих реалиях. Самая вишенка на торте, это когда ты им объясняешь почему именно так, с углублением в смежные темы, и в ответ получаешь что-то вроде: "не, не убедил, бестпрактисы говорят что нужно делать наоборот, придумаешь ещё - приходи". И им абсолютно пофиг что в бестпрактисах слова то вроде похожи, но суть вообще про другое.
TeamLead - это лидер команды. На то он и лидер, что вести людей за собой. Молодое поколение прекрасно поддается воспитанию
P.S. всегда можно напомнить, что у машин есть замечательная вещь - багажник :)
Спасибо за статью!
У меня в команде тимлид придерживается описанных вами правил, и заметно приятнее работать, когда есть доверительные отношения в команде. Плюс, как уже писали тут в комментариях, действительно помогает такие отношения поддерживать то, что и сам тимлид регулярно рассказывает о собственных задачках и том, с чем ему пришлось столкнуться. Ну, и хвалить друг друга на ретре, конечно 😄
Есть ещё одна проблема. Есть такой тип тимлидов, которые не любят делиться интересными задачами. Они используют свое положение, в котором обладают бОльшей информацией (банально в команду заходят с потребностями через лида обычно, ну бывают и другие варианты), и без обсуждений забирают себе самое сладкое. Понятное дело, что все задачи не могут быть интересными и надо разгребать и рутину, но когда ты погрязаешь исключительно в таких задачах, пока твой лид наслаждается челленджами, становится невыносимо уныло.
Да, бывает по разному, лид может сам делать интересное или предлагать своему протеже, возможны варианты. Тут смотреть, что важнее, расти как специалист или комфорт на текущей работе. В других местах тоже есть плюшки и адекватные команды тоже можно найти, если очень поискать.
Согласен, это действительно неприятная проблема, не только для сотрудников, но и я для бизнеса в целом. Тимлид не должен вести себя подобным образом! Задача тимлида - быть лидером команды и проекта, а не приватизировать себе интересные задачи. Челленджами обязательно нужно делиться с командой, чтобы развивать экспертизу
Игнорирование технического долга
Все остальное на этом фоне как по мне несущественно, перманентно замечаю этот косяк у управленцев, которые не занимались разработкой сами, или уровень их компетенций был ниже плинтуса. Объясняешь человеку, что можно задачу решить за час плохо, за 4 на троечку и за день на хорошо (не отлично), и указываешь на риски. Не помню ни разу, чтобы манагер выбрал последний вариант, им всегда все надо "ещё вчера", и будут до упора откладывать рефакторинг, пока это ружье не снесет пол лица функционалу при попытке расширения. Спасибо за статью
0. Игнорирование невысказываемых и главное отчётливо высказываемых и обосновываемых проблем и позиций членов команды. Да, база. Но, к сожалению, существуют тимлиды, которые её игнорируют. Это может скрываться за идеей "о необходимости авторитарности", когда без волевого решения руководителя всё развалится и не соберётся. Однако по факту это является отказом от коммуникации в сфере непосредственной задачи тимлида - собирать лучшее от всей команды и добиваться того, чтобы худшее было нивелировано или обойдено. Без антипримеров, иначе будет депрессовенько.
Согласен, игнорирование проблем команды - также является ошибкой тимлида. Коммуникация - важный инструмент управления, и без нее сложно создать сильную и эффективную команду. Важно не просто слушать, а еще и слышать коллег, учитывать их мнение. Баланс между авторитарностью и открытостью к диалогу - важная задача.
Новые перлы подъехали от зуммера айтишника, который не смог в программирование и его перевели в qa
Признался, что у него не хватает знаний, чтобы протестировать csv файл после нажатия кнопки export на экране списка
Записал в багу красные звездочки у обязательных полей, объяснив это тем, что «неконсистентно, звездочки должны быть на всех полях»
И теперь старший QA миллениал сидит и отлавливает эту дичь.
Базовый набор тимлида: от каких убеждений стоит отказаться, чтобы команда тебя не возненавидела