Путь саморазвития ИТ инженера
В ответ на вопрос «В чём функции роли [Team]Lead?» раз за разом получаю «Распределять задачи в команде и определять приоритеты». Даже в статьях пишут, вот тут, например:
Продолжить чтение «[Team|Tech]Lead в современных реалиях»— распределяет нагрузку среди программистов;
— смотрит за тем, как продвигается задача;
— …
Фантастически вдохновляюще
Ретроспектива — это ритуальное собрание сообщества в конце проекта для обзора событий и изучения опыта. Никто не знает всей истории проекта. У каждого человека есть своя часть истории. Ритуал ретроспективы — это коллективное рассказывание истории и добыча опыта для мудрости.
— Норман Керт — «Ретроспектива проекта»
В данном случае было 100%-е попадание в ожидания от книги. Я ничего особенного от неё не ожидал, я ничего особенного от неё и не получил. Однако дочитал до конца с целью оценить, насколько она может быть полезна для новичков, чтобы понять, тащить ли её на работу, чтобы, например, рекомендовать коллегам.
Вердикт: начинающим, только вставшим на путь скрам-мастера или задавшимся целью включать и бустить самоорганизацию команд, будет полезно. Воды много, много плохо применимых к российскому менталитету примеров, но книжка не большая, выдержать можно. Даёт зачерпнуть ряд важных для развития в этой сфере направлений для дальнейшего изучения. Дальше немного примеров.
Продолжить чтение «Впечатления: М. Лоффлер — «Ретроспектива в Agile»»Давненько не писал я о книгах.
И начну, пожалуй, с более общей, ценной не только для Agile и даже не только для менеджеров.
Чемпион мира по игре в шашки Том Уисуэлл сформулировал эту мысль так: «Игрок, который знает, как играть, обычно играет вничью. Игрок, который знает, почему так надо играть, как правило, выходит победителем». Этот принцип не стоит воспринимать буквально для всех без исключения игр — некоторые игры могут ставить одного из игроков в безвыходное положение независимо от его осведомленности, — однако он содержит зачаток важной общей истины: знание причин дает вам важное преимущество, которого у вас не было бы, имей вы только практические навыки.
Тут в сфере разработки программного обеспечения, кажется, назрел очередной холивар. На тему того, должен ли жить ещё проектный подход в ИТ или все уже должны дружно отмаршировать в сторону подхода продуктового. Кратко и с чувством проблематика донесена в статье «Желаю смерти большинству IT-проектов«. Где прогрессивная сторона представлена Agile-пропагандистами, а консерваторами и ретроградами — последователи PMBOK. Казалось бы, очередная буря в стакане, вызванная недостатком понимания матчасти и смешиванием в одну кучу самых разных факторов и понятий. Продолжить чтение «Проектный и продуктовый подход к созданию ценности»
Пожалуй прошло достаточно времени, чтобы отделить эмоции от ситуации и проанализировать завершившийся опыт работы в компании Paragon Software Group.
Начни я писать подобный анализ чуть раньше, был высокий риск сорваться на типовую историю в жанре «тут все дураки, один я непонятый Д’Артаньян».
Нет, определённо в компании достаточно не просто умных, а очень умных людей, неплохо выстроены некоторые процессы, которые и в более известных компаниях только учатся строить (например, Continuous Integration). Есть и ряд «человекоориентированных» бонусов, в т.ч. уникальных — кофемашины, гибкий график работы, возможность удалёнки, пять «бесплатных» отгулов в год. И Scrum.
В общем, выглядит всё достаточно гибко и инновационно.
Продолжить чтение «Работа в Paragon Software: unexpected end of story»
Ввиду погружения в специфику предметной области управления жизненным циклом ПО, перетряхнул свою электронную библиотеку и нашёл ряд давно добытых и отложенных книг по этой теме. Довольно старых, но тем интереснее было разнообразить поток современной бизнес-литературы. И знаете что? В большинстве случаев старые книги читать увлекательнее, а пользы они дают больше, чем современные.
Это единственная книга из списка, выбивающаяся тем, что прочитал я её ещё пять лет назад. И хоть я с тех пор пять лет не имел отношения к разработке ПО, эта книга стала для меня одной из самых ценных и полезных. Считаю, что для любого менеджера это must read. А если вы ещё и ИТ менеджер, а то вдруг и в области разработки, то просто стыдно должно быть, если вы о ней хотя бы не слышали. Также повлияло то, что большинство книг, перечисленных ниже, ссылаются на эту. Продолжить чтение «Книги августа. Об управлении в сфере разработки ПО»
Личная ответственность командира не зависит от его звания, то есть от степени его узаконенной власти…
«Руководство для командного состава Корпуса морской пехоты США»
(но совсем про Scrum, просто красивая цитата)
Книгу можно было сократить раза в три, поскольку в основе методологии лежит простой здравый смысл и он доносится довольно быстро. Видимо, автору хотелось добавить весомости, поэтому повествование щедро разбавлено психологическими исследованиями и примерами. А также повтором одних и тех же идей разными словами (american style). Но это не умаляет ценности. Продолжить чтение «Впечатления: Джефф Сазерленд — «Scrum»»
Управление проектами — интересная предметная область. Хотя бы тем, что вот уже вторая книга в этой теме, написанная как художественная, а по сути обучающая (первая — «Deadline или Роман об управлении проектами» Листера и Демарко).
Это восхитительное умение — выдать материал не просто в виде фактов и цифр, а вложить в уста преподавателей, читающих курсы MBA, менеджеров, обсуждающих проблемные вопросы за чашкой кофе и профессоров, выступающих перед коллегами и аспирантами, вплести его в художественный сюжет, разбавить эмоциями и переживаниями. Продолжить чтение «Впечатления: Элия Голдратт — «Критическая цепь»»
Уверен, что у качественных учителей большое количество учеников выбирают правильный путь по жизни и становятся грамотными людьми. А у плохих учителей таких учеников немного.
Уверен, что у правильных командиров после армии молодые ребята становятся настоящими мужчинами. А у плохих – разгильдяями.
Уверен, что у отличных руководителей есть много компетентных, честных и крепких выращенных сотрудников, и это настоящий показатель качественной менеджерской работы. А плохие боятся выращивать людей и думают только о том, чтобы не потерять свое место.
Ну так что, сколько людей вы вырастили?
Книга не столько познавательная сколько мотивирующая.
Ну вот прям читаешь, проникаешься и хочется соответствовать. Пусть я не менеджер (по крайней мере, de facto), однако большинство принципов общеприменимы. 45 «татуировок» — это как раз 45 принципов, которыми, по мнению автора, стоит руководствоваться хорошему управленцу. Продолжить чтение «Впечатления: Батырев — «45 татуировок менеджера. Правила российского руководителя»»
SMART — мнемонический акроним, определяющий критерии постановки задач и целей в управлении проектами и людьми.
Specific (Конкретный): Объясняется, что именно необходимо достигнуть. Например, «повысить надёжность и стабильность системы».
Measurable (Измеримый): Объясняется в чем будет измеряться результат. «Сколько вешать в граммах?»(С). Если показатель количественный, то необходимо выявить единицы измерения, если качественный, то необходимо выявить эталон отношения. Например, «повысить надёжность и стабильность системы, сократив количество инцидентов и время их разрешения вдвое».
Attainable, Achievable (Достижимый): Объясняется за счёт чего планируется достигнуть цели. И возможно ли её достигнуть вообще? Например, «повысить надёжность и стабильность системы, сократив количество инцидентов и время их разрешения вдвое, за счёт упрощения конфигурации, написания документации и обоспечения отказоустойчивости путём дублирования компонентов». А вот совершить кругосветный круиз на резиновой уточке вряд ли удастся.
Relevant (Актуальный): Определение истинности цели. Действительно ли выполнение данной задачи позволит достичь желаемой цели? Необходимо удостовериться, что выполнение данной задачи действительно необходимо. Например, надо ли дублировать все компоненты, или только для критичных сервисов.
Time-bound (Ограниченный во времени): Определение временного триггера/промежутка по наступлению/окончанию которого должна быть достигнута цель (выполнена задача). Например, «К окончанию второго квартала следующего года повысить надёжность и стабильность системы, сократив количество инцидентов и время их разрешения вдвое, за счёт упрощения конфигурации, написания документации и обоспечения отказоустойчивости путём дублирования необходимых компонентов».
Принципы логичны и просты, как дыхание. Но куда ни ткнись, менеджмент формата «Вот тебе направление, тут сейчас всё плохо, сделай так, чтобы стало хорошо. И каждый день показывай отчёт о проделанной работе».
Self Engineering 