Comments 17
Да и результаты не описаны.
Эта статья самый обычный самопиар и все.
Одна из немногих полезных на хабре статей от технического руководителя на фоне 100500 статей в стиле "Люся, я тимлид".
Статья — сплошная вода. Все описанное это обычная рутина руководителя, никакого подвига и «бестпрактис» тут нет. То есть совет уволить 5 новчок и нанять 2х профи — много ума не нужно, но у автора явно не было такого кейса (с учетом, что там всего было 10чел), но тем не менее подается это так, как будто это пройденный личный опыт.
Ну и наконец, если такие были обязанности у руководителя, то чем же занимался тимлид в проекте в конце концов, педалил код?)
Нет это не был сарказм. Мой учитель по нормированию, Алексей Антонович Сытин (легендарная личность) на одной лекции рассказал основные принципы построения систем премирования (сейчас это называют кипиай). Принципы эти были очень просты, но очень действенны. И стоили десятка книжек с картинками по кипиай. Здесь тот же случай.
Весной 2019 года меня пригласили руководить разработкой в небольшой стартап, занимающийся обработкой Big Data.
На момент моего прихода в команде были в основном junior разработчики.Во время запуска проекта приходится экспериментировать и срезать углы. Иначе шанс растерять инвестиции до выхода на окупаемость.
Накапливается тех. долг и вас пригласили его погасить.
А дальше 2 сценария консультанта:
— чел работает с командой над исправлением SDLC и тех. долга (профессионал);
— чел зарабатывает себе очки (не зря же наняли, смотрите что я нарыл у этих джунов).
Затем увольняет толпу старых джунов и набирает крутых ребят.
Допускаю, что в вашей статье вы описали второй сценарий, сделали себя героем и решили попиариться.
Поправьте, если я неверно понял посыл вашей статьи.
Я не воспринял это статью как кейс убрать джунов (это один из вариантов). Действительно у любой команды (пусть это будет кафедра в институте или автомойка) есть такая непопулярная функция. Сначала нужно собрать команду, которая поверила бы в успех, сорвалась с места работы и начала пахать за идею. Потом если идея развивается и становится успешной есть дилемма: тянуть "первую" команду, закрепить за ними статус первопроходцев или начинать усиление команды (за счет замены слабых игроков более сильными). Если Вы скажете что "первый" вариант более гуманный чем второй. Я и соглашусь и нет. Я встречался с "первым" вариантом. Выглядит он довольно нелепо, иногда комично. Группа "аксакалов" перестает развиваться и в результате вырождается как специалисты, нанося прежде всего себе вред в своей карьере. Любой "новенький" практически не может сработаться с такой командой, так как начинает работать эффект свой/чужой. В особо тяжких случаях, микроклимат в таких командах больше похож на психиатрический стационар (там где раньше Наполеон Буонопарт был).
Встречал оба сценария. Второй сценарий породил токсичную атмосферу и текучку.
В результате замены новые толковые ребята не захотели вникать в проект. Действительно, разбираться в чужой логике — нелегкая задача. Спустя время ребята просто сливались на более интересные проекты. Выкатывать релизы становилось сложнее и дольше. Бизнес недоволен.
Профессиональный подход: тренировать существующие кадры до нового уровня и добирать новых толковых ребят. Затратно, но эффективно в долгосрочной перспективе. На этом этапе у компании уже есть стабильные деньги.
Команда разработки включала в себя 10 сотрудников: тимлид, front-end разработчики, back-end разработчики, системный администратор и DevOps.А где тестировщик(и)?
Позволю себе не согласиться с тем, что использование классов нужно для группировки. Изобретение ООП связано в первую очередь с понятными абстракциями, схожими с реальным миром. Человеку легче и понятнее с ними работать чем с функциями.
P.S. Наличие интерфейса при одной реализации реализует D в SOLID, то есть позволяет основной бизнес логике не зависеть от деталей (например, делать подключаемые модули)
Эволюция команды разработки