Comments 7
На первой картинке указано: Количество страниц — 396. Время на чтение — 10 часов и 22 минуты. Если округлить, то получится 40 страниц в час.
Даже книги Дарьи Донцовой с такой скоростью не читают, а тут у нас учебное пособие для тимлидов, которое нужно прочитать, выделить полезные моменты, обдумать как эти знания применить на практике к своей команде, сравнить описанное в книге со своим реальным опытом, при необходимости вернуться и повторно перечитать отдельные главы и прочее.
400 страниц)))) Прямо Карл Маркс... На самом деле главная проблема в руководстве коллктивом программисов в том нет возможности оценить сроки и эффективность сотрудников. Когда каменщик кладет кирпичи то тут все понятно - легко прикинуть сколько кирпичей можно положить в час. С программистами все не так. Сплошь и рядом возникают ситуации когда первоночальные оценочные сроки работы отличаются от конечных на проядки. Причем в обе стороны. Даешь задание написать какой то кусок- программист: ни чего готового тут не нашел, буду писать библиотеку три месяца (и ведь реально -сложная штука). Но другой программист смотрит и говорит -нашел тут вот такие библиотеки сейчас их совмещу и к вечеру будет готово. И обратная ситуация, вроде есть куча готовых решений и работы на день. Программист начинает их копать и выясняеться что все они не рабочие, не подходят нам- пишем все с нуля.
Программист который вроде сутками сидит в офисе за компом не отрывясь может быть в десять раз менее эффективен чем тот что приходит к трем часам и то не каждый день, и еще и сидит на рабочем месте с пивом)))
Ни когда еще не видел како-то вразумительного алгоритма для решения этой задачи. Зато видел как кто то тут считает строки кода))) Только херовый программист пишет 100 срок в день и за десять дней пишет библиотеку из 1000 строк. А хроший пишет такую же библиотеку за день , и там у него 10 строк. Исходя из их подхода плохой ппограммист в 10 раз лучьше хорошего...
Говорят, что в 90е, в момент взрывного роста популярности ООП, пытались оценивать программистов по глубине наследования классов. Чем более длинную цепочку наследования написал программист, тем он кучерявее, и тем больше ему надо платить денег. И тогда программисты плодили совсем крошечные почти пустые классы, главная функция которых заключалась в том, чтобы от них плодились бесчисленные потомки.
Метрика успешной разработки продукта - развитие его функциональности. Будь то больше фичей, выше надёжность, улучшение архитектуры и т.п. Если результат работы разработчика (простите за повтор) приближает команду к цели, то он полезен.
Если сложно оценить эффективность по "позитивному" сценарию, т.е. по попаданию в оценку сроков, то можно попробовать "негативный" сценарий, он же "от противного". Повторяет ли разработчик одни и те же ошибки? Не пишет ли он фигОвый код? Насколько качественно он ревьюит чужой код? Это уже даст какую-то базу. А по мере разработки продукта и оценки всё же естественным образом выравниваются, и кратные промахи в любую из сторон становятся всё реже.
Алсо, помогать разработчику в поиске и проектировании решений должен техлид или архитектор. Точнее, если команда разработки постоянно "плавает" в поиске решений, то возможно такой персонаж был бы полезен.
Я читал и "Мама, я тимлид!" и "Карьера Software Engineering Manager". Лично моё мнение - именно для новичка-практика "Мама" гораздо лучше. Лаконичная, конкретная, проблемно-ориентированная. Её я даю читать ребятам, кого промоутят в лиды.
А вот "Карьера" это здоровенный талмуд с текстом в лучших традициях американской школы науч-попа. Автор чрезвычайно многословен, постоянно растекается мыслью по древу и норовит свернуть в какие-нибудь исторические дебри или личные переживания по типу "когда мы были молодыми". Скажу честно, я не смог осилить её целиком и очень много просмотрел по диагонали.
Но есть вариант, когда я бы советовал именно почитать именно "Карьеру". Это отличный обзорник для HR, малоопытных CTO и прочих нанимающих менеджеров, чтобы они понимали, кто такой Software Engineering Manager сегодня и что вообще такой специалист в дикой природе существует.
Карьера Software Engineering Manager. Эффективное управление командой разработчиков ПО — обзор книги и рекомендации