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

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

Фундаментальная проблема IT: как измерить количество выпускаемой продукции?
anton_nix
Вот хочу я например предпринять что-то по улучшению работы компании. Или, хотя бы, улучшить работу команды, разрабатывающей ПО.

Внимание вопрос: как я могу быть уверен, что моё улучшение действительно улучшило работу команды?

Что такое улучшение? Это значит, что:

  • мы увеличили продуктивность, т.е. кол-во изготавливаемого продукта в единицу времени (Throughput в терминах Lean или TOC).

  • мы увеличили скорость поставки (Lead Time), т.е. продукта выпускаем столько же, но время от заказа до поставки сократилось.

  • мы улучшили качество продукции (Quality). Качество в широком смысле: меньше стало дефектов, лучше исходный код (т.е. систему легче стало поддерживать), улучшилось быстродействие и другие нефункциональные характеристики.

  • мы стали тратить меньше ресурсов на изготовление продукции (OE, Operational Expenses). Например, переключили одного человека на другой проект.

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

Cumulative Flow Diagram
anton_nix
Ещё один простой способ увидеть прогресс по проекту: Cumulative Flow Diagram. Пришла она к нам из Lean/Kanban. Отличается от EVM тем, что:

  1. показывает объем работ не в $, а в количестве задач или Story Points. Хотя, нам никто не мешает сконвертировать это всё и в $, т.к. смысл тот же.

  2. на ней не рисуют обычно ни Actual Cost, ни Plan. Первое понятно почему - потому что меряют не деньги, а единицы работы. А второе нам, опять же, никто не мешает дорисовать ;)

Вот стандартная Cumulative Flow Diagram:



Чем мне очень нравится эта диаграмма:

  1. Как видно из картинки, по ней можно отследить сразу кучу полезных канбановских метрик.

  2. Намного спокойнее, когда есть такой эффект, как поздняя интеграция или заказчик тормозит с UAT - видишь, что работа делается нормально, что процесс зависает не на нашей стороне. И, кстати, можно использовать эту диаграмму чтобы пропнуть третьи лица, которые тормозят.

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

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

Вот тут Pawel Brodzinski ещё очень хорошо и подробно расписал при это дело. Спасибо, Джонатану за ссылку! =)
Метки:

Как измерить, идёт ли проект по графику и в рамках бюджета?
anton_nix
У многих менеджеров проектов, их руководителей и заказчиков часто возникает потребность быстро понять, движется ли проект в рамках выделенных сроков и бюджета. Есть способ это очень наглядно и удобно увидеть. Называется Earned Value Management (Метод Освоенного Объема).

Заключается он в то, что вы строите график следующего вида (картинка взята из Википедии), по которому можно быстро понять, что у нас со сроками и бюджетом:


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

GMail: проверка почты по таймеру
anton_nix
Меня в последнее время стало сильно бесить в gmail, что почта сыпется непрерывно в inbox. И даже если проверив почту закрываю ее, то потом нужно что-нибудь найти в старой почте, открываешь, а там уже десяток новых сообщений. И я подумал, что было бы круто сделать проверку почты по таймеру - например, утром, в обед и вечером. А остальное время спокойно работать в состоянии потока на пике эффективности =)

Что я для этого сделал:

1. Настроил спец. фильтр, который всю входящую почту перемещает не в inbox, а в папку incoming, а её скрыл с глаз долой.
2. Сделал скрипт, который в заданное время перемещает всю почту из папки Incoming обратно в Inbox ;)

Да здравствует эффективная работа!

P.S. Оффлайновые клиенты я пробовал и понял, что слишком сильно пристрастился к gmail.

Инструкция тут...Свернуть )

Podcast addict
anton_nix
Нашел классное приложение под Андроид - Podcast Addict. Там есть встроенный поиск по подкастам. Нашел кучу англоязычных по менеджменту и разработке ПО. Очень удобное приложение - можно легко скачать и слушать в оффлайне.

Personal Kanban
anton_nix

Послушал подкаст про Personal Kanban http://www.se-radio.net/2013/07/episode-196-personal-kanban-with-jim-benson/

Надо сделать на месяц доску с карточками-целями примерно одинаковой трудоемкости. И в течение месяца смотреть, как доска освобождается от карточек (новых не добавлять) - походу месяца должно быть примерно равномерно.

Причем цели должны быть интересными.

Потом в конце месяца смотреть, сколько успел сделать.

Попробовать на день тоже брать примерно одинаковой величины задачи и делать их карточками.

На неделю тоже такое надо. Туда включить также и задачи регулярные.

Если все задачи будут примерно одинаковой величины и при этом регулярные будут менее ценными, то их надо делегировать.

Сортировать все задачи по ценности / затраты. Ценность и траты можно определить попарным сравнением.


Должен ли МП быть технарем с точки зрения управления рисками?
anton_nix
С точки зрения управления рисками этот вопрос, наверное, довольно прост: квалификация (и, следовательно, зарплата) МП измеряется в количестве рисков, которые он знает и умеет мониторить, и насколько качественно он умеет их ослаблять.

Т.о. МП с техническим бэкграундом может намного лушче определять технические риски и как их ослаблять. Вопрос в том, насколько важны эти технические риски?.. Например, RUP считает, что архитектурные риски одни из самых главных. Хотя, риски непонимания требований тоже.

Должен ли МП быть технарем с точки зрения Мицберга?
anton_nix
Можно посмотреть на эту проблему под углом книги Мицберга "Структура в кулаке". Если компания имеет проектную, т.е. рыночную ориентацию, то МП становится основным руководителем на проектах и отвечает за них. Имеем эффективную ориентацию на клиентов. Если же МП не главный, если мы позиционируем его как "чисто администратора", то получается, что мы подталкиваем компанию к функциональной структуре.

Со всеми вытекающими - у функциональной структуры есть свои плюсы и минусы, у рыночной - свои.

Предположим, что мы решаем ориентировать компанию к рынку. Каким тогда должен быть МП? Может быть ответ в книжке и есть, но я еще не дочитал =)

Должен ли МП быть технарем?
anton_nix
Извечный вопрос: должен ли МП быть технарем, т.е. иметь опыт работы в качестве рядового аналитика, разработчика, тестировщика в ИТ? Чтобы наконец-то его для себя разрешить, попробую обновлять этот пост регулярно, пополняя наблюдениями с полей, подтверждающими или опровергающими эту гипотезу.

11.03.2014

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

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

Я считаю:

  1. Если всегда спрашивать мнение эксперта, то зачем нужен МП? Если он всегда спрашивает мнение всех, то он либо коуч, обладающий техниками вытягивания решения из людей. Либо он секретарь, который выполняет функцию перенаправления потоков информации нужным лицам - умеет просто отделять какие вопросы к кому должны идти. Но ни в том, ни в другом случае он точно не должен тогда нести ответственности за проект - ни коуч, ни секретарь ответственности за решения, сделанные экспертами, не несут.

  2. Эксперты - люди узкой направленности и часто их немного на компанию. Они "пилятся" между многими проектами и не знают их контекст достаточно хорошо. А контекст часто играет важную роль.

  3. У экспертов мало времени и за каждым решением к ним не побегаешь.

  4. Практика практикой, а как говорит Талеб, платонизм никто не отменял: практика - штука обманчивая, можно очень легко связать причинно-следственной связью события, которые на самом деле ей не связаны. Нужен научный подход, а не интуитивный. А для научного подхода нужны хотя бы фундаментальные теоретические знания, а не практические.

Обед: заказчику пришлось обосновывать план работ - что необходимо сначала проработать юзкейсы, потом набросать архитектуру, по наиболее критичным юзкейсам, а потом делать прототип для проверки рисков.

Как МП обоснует этот подход и план работ заказчику, да и членам команды, если он не понимает:

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

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

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

Вечер: меня пытался залечить один опытный тестировщик, что тестирование проекта невозможно, и что ему нужна тьма времени на тестирование т.к. там недостаточно детально проработаны требования и тяжело сделать тестовые данные. При этом используя кучу профессионального жаргона и умных слов.

Если бы на моем месте был МП, не владеющий терминологией RUP и большим техническим опытом и знаниями, не знаю, чем бы это кончилось. Скорее всего МП бы отказался от идеи продать тестирование заказчику, т.к. слишком уж неоправданно высока была бы цена, а почему она такая объяснить бы он не смог. Заказчик бы покрутил и у виска. Тестировщик ушел бы довольный - МП бы пошел у него на поводу.

12.03.2014

Ни в одной методологии на МП не ложится ответственность за проект, если у него нет квалификации.

МП должен понимать заказчика - его термины и понятия. МП должен понимать команду.

МП не тех - либо заказчик увидит, что он не сечет, либо, что он никто. Уровень квалификации обратно пропорционально как часто звать эксперта.

16.03.2014

МП требуется планировать работы. А среду работ есть работы для программистов: создать такой-то компонент, другой, третий. И МП должен понимать, что это за компоненты, к каким фичам они относятся и соответственно эти работы распределять в плане. Хотя, конечно, если аккуратно ведется трассировка, то это превращается в почти механическую задачу. Но трассировку еще контролировать надо - как она ведется...

Или в SCRUM в-принципе все работы - фичи, понятные пользователю и тут как бы не надо быть тех. спецом. Но периодически возникают вопросы относительно не только фич, но и рефакторинга и KISS, и тут опять же надо понимать.

18.03.2014

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

27.06.2014

Подумалось следующее: мы хотим, чтобы менеджер проекта нес ответственность за проект. Что в частности означает, что он должен: 1) знать когда привлекать того или иного специалиста (аналитика, разработчика, тестировщика, архитектора и т.д.), значит он уже должен знать где кто нужен. 2) уметь на каком-то уровне проверить качество работы человека. Например, разработчики говорят, что аналитик плохо наанализировал - МП должен уметь понять, кто прав, кто виноват. Иначе придется вовлекаться функциональным руководителям, а может даже и директору.

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

Вообще, Мицберг про это дело пишет, что у проектного и функционального руководителя власть и ответственность примерно одинаковые. Возможно как раз по этой причине...


Помидорный тайм-менеджмент для менеджеров проектов
anton_nix
Последние 7 месяцев опять начал пользоваться помидорной техникой (почитать про нее можно на сайте или в книге). Результаты, по субъективным ощущениям, потрясающие:

1.      Продуктивность повысилась процентов на 30%!

2.      Стал намного меньше уставать. Если раньше приходил с работы без задних ног, то сейчас стал намного лучше себя чувствовать. Несмотря на весну и авитаминоз =)

3.      Задачи стали выполняться намного качественнее.

Далее, небольшая история J

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

?

Log in