Pull to refresh

Comments 30

Ни в коем случае нельзя доделывать работу за других. Сам с этим борюсь. Нужно чтобы человек самостоятельно доделал все до конца, иначе привыкают просто бросать на определенном этапе. И самое сложное это учить человека делать конечный продукт, а не набор классов и методов. Что на этапе успешной компиляции все не заканчивается, а нужно еще документацию сделать и отследить как с этим будут работать, оценить удобство и подумать как можно сделать проще.
«Ни в коем случае», наверное, слишком сильно сказано, но согласен, привычка вредная и может создать «узкое место». Добавлю оговорку. Большей частью доделывание за другими провоцируется нехваткой времени.
Я порой просто не могу ждать, пока сотрудник сделает таск, так как от него зависят другие — приходится доделывать самому =\
Да, в такие моменты соблазн особенно велик, но надо держаться. :) Если что-то очень сильно тормозит, то я просто прошу сотрудника вставить быструю заглушку, чтобы остальные могли делать свою часть работы. И сразу же пишу таск на доделку. Как правило, сотрудник после текущей задачи сразу доделывает такие «висяки».
а как же доделывание за уволенными?
Увольнение обычно согласовывают с начальником, и у уходящего сотрудника есть время завершить висящие на нём задачи.
Все зависит от «сотрудник уходит на повышение» или «сотрудника попросили уйти» ибо намучались с ним.
Но вообще еще не разу «дембельский аккорд» ни к чему хорошему в итоге не приводил
Если возможно, то напишите, пожалуйста, статью о своём опыте, задачах и способах решения.
Было бы интересно еще почитать статьи на эту тему.
Спасибо
> Короткая память ухудшилась. Переваривание больших объёмов информации поначалу перегружало мозг. Я начал его разгружать, и это привело к тому, что он в принципе отвык запоминать то, что не записано. Возможно, это верно только для моего случая.

Вы, увы, не уникальны в этом… Мозг хитрый, всегда найдет возможность что-то соптимизировать)
самые основные вещи имеет смысл определить, зафиксировать

А не могли бы Вы привести более-менее конкретный пример тех вещей, которые у вас задокументированы?
Учёт рабочего времени
Жизненный цикл задач в системе контроля версий
Работа с репозиториями
Проведение ревью
Работа с сервисом для тестирования приложений
Предоставление доступов к сервисам и проектам

Гайдлайны разработки
Порядок оценки проектов
Работа с continuous integration
Порядок ведения репозиториев с переносимым кодом

Введение разработчика в компанию
Порядок проведения собеседований

Ну и специфичные вещи по мелочи
Не прекращается ли саморазвитие техлида ввиду выполнения большого объема менеджерской работы и соотв. потерю стоимости на рынке труда как специалиста?
Стоимость у лида не теряется
Никто не мешает держаться ближе к разработке и становиться только лучше, получая уникальный опыт
Это может привести к тому, что разработчики проводят исследования, пишут код, используют новые библиотеки, а техлид снимает «сливки».

Он получает этот опыт за небольшое время, пишет об этом статьи на хабре и ездит по конференциям, представляя результаты работы своей компании (читай, своих разработчиков).

Вижу здесь два негативных момента:
  • Простые работяги, которые пишут код (и именно их результаты пиарит техлид), завидуют своему боссу, который зарабатывает известность и ачивки для линкедина.
  • На этих конференциях на вопросы по нюансам техлид может и не ответить.
Это уже о людях, а не о должностях. Стоит ли пиариться на чужом труде, не имея о нём полного представления — на совести лида. Нужно ли самому презентовать результаты собственной работы и стоит ли терпеть неуважительное отношение — решения разработчиков.
Ну это не техлид получается, а менеджер.

У тех лида своя своя своебразная ниша, конечно он не очень менеджер и не очень разработчик. Конечно если его брать как разработчика то он будет явно переоценен.
Если его брать как менеджера у него не будет ряда менеджерских качеств. Да и не архитектор он.

Но у него есть свои качества которые и ценятся: знание общей архитектуры, техническое управление несколькими проектами, общее понимание архитектур. Владение кодом как правило в самых проблемных местах.
В целом как программера ценность падает потому что программерские знания падают. Грубо говоря, программер который занимается программированием 8 часов будет знать в 2 раза больше, чем тот который занимается 4 часа (как например техлид). А если тебя ещё постоянно отвлекают, то понять что-то глубоко у тебя выйдет с трудом.
Но с другой стороны техлиды часто могут воспользоваться своим служебным положением чтобы отбирать себе интересные развивающие задачи, в то время как у программеров такой роскоши часто нету. Делать похожие задачи 8 часов под ряд не особо развивает конечно.
Хороший техлид не будет забирать интересные задачи себе. Хороший техлид отлично знает свою команду, знает их интересы и найдёт того, кому можно было бы выписать премию в виде интересной задачи.
Передача задач и проста, и сложна — нужно проверять, кто свободен на данный момент, лично обращаясь к разработчикам и менеджерам проектов. Мне пока не удалось придумать ничего эффективнее обычного диалога, хоть чутьё и подсказывает, что должна быть какая-то возможность сделать это проще и прозрачнее.

Тоже страдаем у себя в компании, перебиваясь чатиками да заметками… Треккер типа редмайна — слишком неповоротлив для контроля оперативной обстановки, какая-нибудь диаграмма ганта — протестировал кучу решений, почти везде за основу берется «прокет», на коротый распределяется «ресурс», и дальше предполагается, что этот «ресурс» так и остается на проекте.

В реальности же, когда приходит дедушка факап, ресурсы безжалостно перетасовываются между проектами, картина за неделю может сильно поменяться. В этом плане было бы удобнее иметь другой вариант «ганта»: когда в основе у нас лежит разработчик, а к нему уже цепляются проекты, с указанием, с какой по какую даты в каком объёме он каждым из них занимается. Но пока подходящего решения такого типа не нашли. Откопали ganttic.com, но это ж, блин, космический корабль, поддерживать его в актуальном состоянии — всё равно что второй редмайн вести.

Если есть идеи/прозрения/советы по этому вопросу — был бы весьма благодарен.
Трелло и всякие agile борды. Общую выжимку с командных и проектных trello можно свести в дашборд. Получается понятно и удобно для всех.
У меня в команде прижилось трелло. До этого пробовал TFS и Youtrack — для коллег очень тяжело было полноценно вести их.
Можно посмотреть еще Kaiten.
Мы используем для этого диаграммы-ганта на основе Float и дополнительно ввели правило: один разработчик — один главный проект — один ответственный менеджер. В том случае, если что-то загорается, то менеджер загоревшегося проекта обсуждает с ответственным за текущий проект менеджером, когда он может его освободить и на сколько. Техлид в данном случае является арбитром. Это даёт возможность передоговориться с клиентом о новых сроках заранее и не нарушать планы клиента.
Спасибо за статью, отлично оформленный материалл. У меня пару вопросов:
— В процессе формализации у вас получается очень много документации, где вы ее храните и как организован поиск нужного документа.
— Как вы организовываете процесс обучение мидлов или изучение новых технологий? есть ли какие-то критерии оценки результата обучения?
Информация хранится в wiki redmine (решение со своими особенностями, но работает). Ссылки на статьи лежат на главных страницах общедоступных проектов (общие на компанию — в проекте компании, специфичные для отдела — в проекте отдела) и легко там находятся. Вообще искать разработчикам ничего не надо, потому что документы входят в состав системы обучения и изучаются в её рамках.
Мидлы обучаются как и все остальные — в систему обучения входит база знаний до сеньоров включительно. Новые технологии, касающиеся обновления SDK, разбираются командой после презентаций, по ним пишутся статьи. Новые подходы к написанию приложений проверяются на проектах.
Вопросы не ко мне, но мне охота ответить :)
1. Документация в Confluence. Проблема в том что если большинство документацию не пишет, то не будет привычки искать документацию в нужном месте.
2. Реальные задачи даём. Давать теорию (в том числе knowledge sharing по существующим проектам) без практических задач не эффективно.
Вообще подход к обучению не зависит от того какой у программера левел.
Хотя часто встречал подходы когда программер должен сдать теорию по технологиям в формате интервью чтобы повысить левел.
А что делать, если лидов слишком много? У меня четыре-пять лидов, которые постоянно спрашивают «когда сделаешь?». Всех удовлетворить не получается. :) Я даже скайп отключил, что бы пешком не ленились ходить.
Держать задачи в баг трекере в актуальном состоянии и просить их смотреть туда.
Sign up to leave a comment.