?

Log in

No account? Create an account

Про ИТ-менеджмент

Постараемся сделать мир чуточку счастливее

Про красные лампочки
anton_nix

Заметил, что в некоторых компаниях любят делать развесистые дашборды с метриками по проектам. Там мигают красивые разноцветные лампочки, каждая из которых отражает состояние проекта в том или ином разрезе: сроки, бюджет, риски, качество и т.д.

Причём, народ любит этот дашборд постоянно улучшать, доплнять и уточнять. Придумывать алгоритмы по которым лампочки будут показывать супер-точный статус.

Забавно следующее: когда такой дашборд вводится впервые, и ещё долгое время после этого, на нём горит куча красного раных оттенков, но при этом никто особо не чешется, чтобы что-то с этим делать -- работа как шла так и идёт в своём собственном темпе. А какое-нибудь начальство, для которого вроде бы как этот дашборд и был сделан, говорит что он слишком сложный и не смотрит на него. И, конечно же, ругается когда на каком-то проекте совсем уже пожар, вопрошая, почему же никто заранее не предупредил что проблема зреет?

Как же должны в идеале выглядеть работа с дашбордами?

Главная цель: помочь правильно распределить ресурсы, интеллектуальные и другие. Т.е. вовремя привлечь к проекту более опытных товарищей, больше вовлекаться начальству (которое теоретически должно быть как раз более опытным).

У компании есть ряд проектов. На каждом свои риски -- риски обычно размазаны неравномерно. Ну и риски на то и риски, что на одном проекте их "выстрелит" больше, а на другом меньше.

Читать дальше...Свернуть )

Не назначайте регулярных совещаний!
anton_nix

Хочу поругать регулярные совещания. Только не с традиционной позиции тех, кто в них участвует. А с позиции тех, кто их назначает -- начальников. 

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

Под сферой ответственности я тут понимаю какой-то конкретный проект или активность (например, регулярную сессию обсуждения проектных рисков).

Но, почему же регулярные совещания -- это плохо?

Как правило, в любой сфере ответственности всегда есть какие-то проблемы или вещи, которые можно улучшить. Поэтому обсуждение любой сферы занимает всё отведённое под неё время. Таким образом, назначив еженедельное совещание в час продолжительностью, вы гарантированно будете его тратить -- весь этот час.

Читать дальше...Свернуть )

Analyst Days 2016
anton_nix

Первый раз участвовал в Analyst Days.

Вцелом конференция мне понравилась больше чем Agile Days: полезных докладов было больше. Наверное, потому что участников меньше, и потому что я не аналитик ;) Хотя, мне было всё понятно, никаких космических технологий я не увидел.

Атмосфера была более душевная, что странно, ведь в теории это РМы должны быть общительными и лапными существами. Но и лидерами, а лидер, он всегда один, видимо, причина в этом.



Организация тоже на уровне, хотя над сайтом, кхм, стоит поработать: неудобная навигация и глючная мобильная версия. Ну и было много докладов длинной в час или (!) дольше, на мой взгляд так делать нельзя - докладчики высасывают речь из пальца, начиная из далёкого далёка, а слушатели скучают половину доклада.

По докладам, где я был.Читать дальше...Свернуть )

Игра-симуляция "Кораблики" по принципам Канбан и теории ограничений.
anton_nix
Проводил на Дне Экспертизы Тамтэк игру-симуляцию. Презентация здесь.


Полезные отчеты. Меньше букв, больше смысла
anton_nix
Видео с выступления на Дне Экспертизы Тамтэк от 28 января.

Какому проекту какая методология. Удачная модель
anton_nix

Раньше я часто сталкивался с вопросом: когда какую методологию использовать, какая лучше и т.д. Теперь, мне кажется, пришел к довольно удачной модели.

Основные факторы, влияющие на методологию

В статье Коберна “Каждому проекту своя методология” указаны следующие основные факторы:


  • Критичность продукта. Одно дело разрабатывать интернет-магазин и другое - ПО для АЭС.


  • Размер команды. Кол-во коммуникаций растёт квадратично, поэтому их часть начинает заменяться на формальные документированные.



Для нас, аутсорсеров, также очень важен фактор:


  • Доверие заказчика


Потому что недоверие обычно означает строгий контроль, фиксированный контакт и большие проблемы с оценкой, планированием и рисками.


Около года назад я стал выделять еще один фактор, который часто влияет больше всех остальных:

Читать дальше...Свернуть )

Техника пустого инбокса Максима Дорофеева с помощью сервиса Remember The Milk
anton_nix
Мне нравится тайм-менеджерская техника пустого инбокса Максима Дорофеева (mnogosdelal.ru). Для неё не требуется никаких сложных инструментов, ежедневника хватает. Но я много времени работаю за компом, поэтому веду задачи в электронном виде.

Ещё до знакомства с техникой использовал сервис Remember The Milk (RTM). Люблю его за гибкость - благодаря "умным" спискам затачивается под любую методику. Если пользуетесь смартфоном, то приобретите pro-аккаунт за $25/год, иначе синхронизация с веб-сервисом возможна только 1 раз в сутки. Хотя, некоторые люди работают через мобильный сайт m.rememberthemilk.com.

Настройка RTM под технику пустого инбокса:
Читать дальше...Свернуть )

Метрика: Уровень Риска
anton_nix
Пол-года практикуем Управление Рисками в Тамтэке. Текущие проблемы:

  1. Цель - обновлять риски еженедельно. По 20% проектов этого не делается.

  2. У рисков мутное описание, поэтому никто не может помочь РМу бороться с ними.

  3. РМ не регистрирует специфические для проекта риски, а указывает только стандартные, с которыми живут все проекты. А с ними есть стандартные правила борьбы, поэтому начальству нет смысла получать отчёты по ним. А со специфическими РМ воюет в одиночку, никому не сообщая.

Две недели назад ввели новую практику - диаграмму уровня рисков на проекте:


Читать дальше...Свернуть )

Статистическая оценка проектов
anton_nix
Представьте, что вам больше не надо оценивать проекты. Заказчик даёт вам перечень работ, и вы за 5 минут называете ему, сколько времени и денег это займет. Конечно, это недостижимый идеал, но как к нему приблизиться рассказывает Трой Магеннис на этом видео:


Actionable Agile Metrics for Predictability
anton_nix


Прочитал книгу, посоветованную Джонатаном. Почерпнул много полезного:

  • Что у закона Литтла, который очень любят исповедующие канбан, есть ряд допущений, без которых он не работает.

  • Что Cumulative Flow Diagram тоже не работает в ряде случаев.

  • Что Scatterplots, оказывается, очень-очень полезные.

  • Что есть такая штука Lean Forecasting, которая позволяет достаточно точно статистически оценивать дальнейшие работы по проекту. Без экспертных оценок. Без затрат времни на оценку. Вообще.

В особенности меня зацепили последние две штуки.
Читать дальше...Свернуть )