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

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

Функции менеджера проектов
anton_nix
Больше двух лет назад я написал в блог, что из-за неопределенности функций менеджера проектов есть очень много проблем. И даже нарисовал Дерево Текущей Реальности по этой проблеме. Теперь я стал понимать, как решить, эту ключевую проблему.

Итак, кто такой Менеджер Проекта? Можно посмотреть на эту роль с нескольких позиций:

  1. Менеджер проекта - как професссионал.

  2. Менеджер проекта - как ответственный за успех проекта.


Менеджер проекта - как профессионал

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

SWEBOK (Software Engineering Body of Knowldege) поддерживает эту точку зрения. В SWEBOK есть дисциплина Software Engineering Management. В ней говорится, что менеджер проекта должен обладать вполне конкретными знаниями.




Я считаю, что любой менеджер проекта должен также хорошо знать:

  • Software Engineering Process.

  • Software Engineering Models and Methods.

  • Software Engineering Professional Practice.

  • Software Engineering Economics.

Ну и хотя бы основы остальных дисциплин. Полный список можно найти в SWEBOK.

Интересно, что если представлять менеджера проекта, как профессионала, то тогда для оценки его работы можно использовать все классические инструменты оценки персонала:

  • матрица компетенций - таблица, где строки - функции/навыки, а столбцы - уровни владения ими.

  • карьерная лестница

  • проверка выходных артефактов - выполнение каждой функции может иметь своим результатом изменение какого-то документа, соответственно это можно проверить.


Менеджер проекта - как ответственный за успех проекта

Во-вторых, менеджер проектов должен отвечать за проект. Тут писать скучно, т.к. это как раз классическое представление о матёром менеджере проектов - что он Руководитель. Если на проекте какая-то проблема, то в конечном итоге отвечает именно он.

Сейчас в мире представление о менеджерах проектах разделилось на две точки зрения. Где-то на менеджеров проектов смотрят просто как на члена проектной команды, который выполняет вышеперечисленные функции. А где-то считают, что менеджер проекта должен именно отвечать за проект.

Давайте определим, что же значит отвечать за проект?

Это значит, что менеджер проекта не может никогда сказать "я не виноват! Это программисты/тестеры/аналитики накосячили!" - доля вины всё равно ложится на него, как на руководителя. Это именно он не создал условия, не набрал команду, не настроил процесс так, чтобы косяков был минимум, чтобы их быстро исправляли и т.д.

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

Некоторые открытия по результатам тренинга по джедайской технике пустого инбокса
anton_nix
В декабре у нас в Тамтэке проходил тренинг Максима Дорофеева (cartmendum) по технике пустого инбокса. Основной смысл техники, и главное отличие от других техник тайм-менеджента, по-моему, в том, как перестать откладывать дела на потом (прокрастинировать).



Другие техники тайм-менеджмента обычно учат другим вещам:

  1. как ничего не забыть

  2. как распланировать дела на будущее

  3. как расставлять приоритеты

Но мало учат тому, как заставить себя делать дела, т.е. перестать откладывать выполнение этих своих замечательных планов. А вот Макс учит, за что огромное ему человеческое спасибо!

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

Фундаментальная проблема 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
Можно посмотреть на эту проблему под углом книги Мицберга "Структура в кулаке". Если компания имеет проектную, т.е. рыночную ориентацию, то МП становится основным руководителем на проектах и отвечает за них. Имеем эффективную ориентацию на клиентов. Если же МП не главный, если мы позиционируем его как "чисто администратора", то получается, что мы подталкиваем компанию к функциональной структуре.

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

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

?

Log in

No account? Create an account