Управление Программными Проектами: Процессы, Инструменты, Методы

Существуют разные представления о том, как осуществляется творческая работа.

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

Управлять информацией? О, нет! Это невозможно! Тем не менее задача управления творчеством всегда была актуальной.

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

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

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

Ежегодно продается более 10 миллионов копий.

Годовой доход: $1 млрд. Допустим, мы хотели открыть ресторан.

По каким критериям Клиент это оценит? Конечно, это кухня, дизайн и сервис.

Обычно наибольшее количество «сбоев» возникает в процессе технического обслуживания, т.е.

там, где велик человеческий фактор.

Красивая молодая официантка, кажется, привлекает клиентов.

Но у нее испортилось настроение, и вместо доброжелательного отношения она начинает грубить.

В результате вместо привлечения Клиенты разочаровываются.

Это просто неприемлемо в индустрии разработки программного обеспечения.

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

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

В крупных проектах выгоднее купить на рынке нужного специалиста, даже если его зарплата кажется завышенной.

Снимая фильм, продюсер не учит своего сценариста писать диалоги, если тот не умеет это делать, а просто покупает сценариста для написания диалогов на рынке.

То же самое касается и разработки приложений.

Если между командами из разных стран возникает недопонимание, то одну команду отправляют в длительную командировку.

При миллиардных доходах командировочные расходы не имеют значения: главное — выпустить продукт вовремя.

Опции управления

Только в школе людей учат мыслить как функцию одной переменной.

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

Пример.

Одна компания, занимающаяся мобильными играми, записывала задачу на карточке и помещала ее на доску.

На доске было нанесено несколько вертикальных полос.

Каждая полоска соответствовала определенному состоянию задачи.

Новые задачи разместили в крайнем левом ряду.

Затем, по мере завершения, они постепенно перемещались вправо.

Главным критерием успеха руководство считало перемещение карты на доске слева направо.

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

Еще одним недостатком является количество решаемых задач.

В нашем проекте за первый месяц нужно было выполнить 200 задач.

Понятно, что разместить на доске столько карт было физически невозможно.

Вот список параметров, которые должен контролировать менеджер проекта: 1. Сроки.

2. Громкость (количество полезных функций).

3. Объем работы.

4. Полезность (ценность для Потребителя).

5. Техническая и технологическая сложность.

6. Внешнее качество (с точки зрения Потребителя).

7. Внутреннее качество (с точки зрения специалиста, инженера, проектировщика).

8. Риски.

9. Психологическое состояние команды.

Процессы управления

Перечислим некоторые процессы, которые будут обсуждаться ниже: 1. Управление задачами.

2. Управление сроками.

3. Управление качеством.

4. Управление рисками.

Управление задачами

Цель

Система контроля задач

Цели

Примечание.

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

Пример.

На одной работе у меня был начальник, который на вопрос «К какому сроку выполнить эту задачуЭ» - всегда давал один и тот же ответ: «Вчера».

Позже, когда я стал начальником, я убедился, что с программистами происходит зеркальная ситуация.

Спросите кого-нибудь: «Когда ты закончишь эту работуЭ» - и получаешь ответ: «Завтра к обеду.

В худшем случае к вечеру».

Но проходит день, другой, а задача все еще не выполнена.

Чтобы как можно реже попадать в такие ситуации, вам нужен инструмент, который регулярно сообщит вам оставшийся объем работы.

2. Распределите задачи между работниками.

Убедитесь, что у каждого работника есть своя задача и никто не бездействует. Примечание: По данным министра экономического развития России (21.05.2012 – 24.06.2013) Андрея Белоусова, производительность труда в нашей стране в 2-3 раза ниже, чем в развитых странах, в зависимости от метода расчета ( http://www.forbes.ru/kompanii/245905-v-kakikh-otraslyakh-rabotayut-samye-neeffektivnye-rossiiskie-kompanii ).

Пример.

Если вы когда-нибудь наблюдали аварию на ремонтируемой теплотрассе, то наверняка замечали, что один рабочий роет яму, а вокруг него стоят 10 человек и смотрят, как он работает. Вы также должны следить за тем, чтобы сотрудники не пренебрегали одними задачами в ущерб другим.

Пример.

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

В результате, если Покупатель захочет приобрести муфту или обжим, посоветоваться не с кем.

Вот как продавцы выполняют одни задачи и игнорируют другие.

Получается, что сотрудники ставят или выбирают задачи, которые «вкуснее» для себя.

3. Найдите зависимости между разными задачами.

Примечание (Василина Абу-Навас, бизнес-консультант ассоциации «Практик»): Задача должна соответствовать задачам других сотрудников, всего проекта или его части.

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

Например, президент путешествовал.

Об этом знали давно, просто «забыли» предупредить.

А те, кто «копал», как обычно, не уточнили параметры своей задачи.

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

То есть .

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

4. Определить, какие задачи заблокированы по той или иной причине.

Пример.

По стандартам газеты «Коммерсантъ» одно время материалы журналистов, рисунки художников и фотографии фотожурналистов нужно было сдать до 18:00. В редакции также есть специальный человек – рерайтер, задача которого – привести все тексты в единый стиль.

Описание

Таблица 1. Перечень задач мобильной системы GPS-навигации

Параметры

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

• Добавьте экран поиска перекрестков.

  ( Примечание: Проверяемый критерий – экран.

  Он либо есть, либо его нет.)

• Узнайте, почему не строится маршрут через КАД в Санкт-Петербурге.

  ( Примечание: Проверяемый критерий – построение маршрута через кольцевую дорогу.

  )

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

Примеры:

• База данных – Поиск мест – Добавить парикмахерские в базу данных по России.

  ( Примечание: Задача относится сразу к двум направлениям: с технической точки зрения – к базе данных, т. к.

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

  )

• Интерфейс – Карты – Добавьте новые стили оформления карт. ( Примечание: Эту задачу также можно отнести сразу к двум разделам навигационной системы: пользовательскому интерфейсу, где можно выбрать стиль оформления карты, и подсистеме визуализации карты.

  )

Это позволит вам «собрать статистику» и оценить объёмы работ, связанных с той или иной частью программы.

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

Круговая диаграмма лучше всего подходит для визуального представления статистики:



Рисунок 1. Объем работ по мобильной системе GPS-навигации Статус задачи позволяет определить, какие задачи уже выполнены, какие находятся в процессе, а работа над какими задачами еще не началась.

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

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

Пример.

Задание «Заменить значки» невозможно выполнить, если художник не успел нарисовать эти значки.

Остаточная трудоемкость содержит текущую оценку задачи — сколько времени осталось до выполнения задачи.

Его выдает подрядчик в конце каждого рабочего дня.

Таким образом, задача регулярно переоценивается.

Это позволяет отслеживать прогресс и вовремя принимать определенные меры, если команда не укладывается в сроки.

Применение

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

Над проектом рекомендуется работать итеративно – двухнедельными или еженедельными итерациями.

(Итеративность помогает быстро выполнить какой-то выполненный кусок работы и быстро получить обратную связь.

) В начале каждой итерации выполняется детальное планирование, в результате которого выбираются задачи для итерации.

При необходимости задачи детализируются, уточняются их формулировки и оценки.

К

• ? Таблицы Excel или Документы Google.
• Редмине http://www.redmine.org
• Джира - https://www.atlassian.com/software/jira
• БагЗилла http://www.bugzilla.org
• DropTask http://www.droptask.com
• Хансофт – http://www.hansoft.com

Управление сроками

Цель

Диаграмма сгорания задач

Цели

Пример.

Самый распространенный подход к управлению сроками — это наблюдение на глаз: «Сможете ли вы выполнить задачу к пятницеЭ» В наиболее яркой форме с таким подходом я столкнулся в российско-немецкой компании.

В первый день работы ко мне подошел хозяин-немец и спросил: «У меня день рождения через три месяца.

Успеете ли вы выпустить игру ко моему дню рожденияЭ» 2. Определить размер лагов по плану.

3. Оценивайте прогресс каждого сотрудника и всей команды.

Примечание.

В этом случае будет семейство диаграмм.

Диаграмма

Описание

Вместо одной цифры указаны две цифры — сколько времени осталось на самом деле и сколько должно было остаться по плану.

Таблица 2. Прогресс сотрудников

Параметры

Один из них (нарисован пунктиром) показывает планируемое сокращение объёма работ, т.е.

так, как оно должно быть.

Вторая кривая (нарисованная сплошной линией) представляет фактическое изменение объема работы.

Каждая точка на этих кривых представляет собой запланированный или фактический объем работы, оставшийся на конец дня.

Применение

В конце каждого рабочего дня данные – объем оставшейся работы в часах – заносятся в таблицу.

Данные берутся из графы «Остаточная трудоемкость» таблицы задач.

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

Контроль качества

Цель

Пример.

В 2013 году в России количество разводов составило 54,5% от числа зарегистрированных браков ( http://womanadvice.ru/statistika-razvodov-v-rossii ).

Такое количество «дефектов» в индустрии разработки программного обеспечения просто недопустимо.

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

Но это делается при разработке программного обеспечения.

Крупные корпорации планируют качество продукта еще до начала разработки.

Они не только прогнозируют количество дефектов, которые будут обнаружены в ходе проекта, но и количество дефектов, которые не будут исправлены.

Пример.

В одном из проектов было обнаружено 30 тысяч (!) дефектов.

Из них 15% так и не были исправлены.

Несмотря на то, что это некритические или очень редкие ошибки, все же можно сказать, что приложение вышло с 4500 ошибками.

Прогнозируемое количество дефектов

Цели

1. Оцените сложность проекта.

2. Оцените ресурсы, необходимые для улучшения качества.

Описание

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

Таблица 3. Прогноз количества дефектов мобильной системы GPS-навигации

Параметры

Их можно получить логическим разделением по разным основаниям.

Иногда программа делится на части с точки зрения пользователя (как показано в таблице ниже).

В других случаях используются технические критерии.

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

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

Применение

Учитываются исторические данные, прогнозируемый объем работ, сложность требований к новой версии приложения, а также опыт самой команды.

Прогноз дается по подсистеме.

Для повышения точности используются две разные модели.

Первая модель предполагает разделение программы на подсистемы по различным техническим критериям.

Например:

• Пользовательский интерфейс
• База данных
• Аудио
• Алгоритмы

Например:

• Рисование карты
• Построение маршрута
• Навигация
• Поиск адреса

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

Это помогает определить количество инженеров по качеству, которые будут привлечены к проекту.

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

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

Пример.

В одном из проектов фактическое количество дефектов оказалось ниже прогнозируемого значения.

По статистике, инженеры по качеству не выполнили свою работу, потому что… обнаружили меньше ошибок, чем предполагалось.

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

доработка по выходным.

План поиска дефекта

Как правило, за единицу времени выбирается неделя.

Цели

1. Распределите ресурсы, ответственные за контроль качества, во времени.

2. Получить механизм контроля работы инженеров по качеству.

Он основан на ранее сделанном прогнозе путем распределения общего количества дефектов по неделям проекта.

Команда инженеров по качеству еженедельно получает задание — сколько дефектов в программе она должна найти в течение данной недели.

Еженедельные задачи можно детализировать по дням и сотрудникам.

В результате будут получены задания для каждого инженера на каждый день.

Описание

Таблица 4. Еженедельный план поиска дефектов мобильной навигационной системы GPS

Параметры

количество дефектов, которые будут обнаружены в нем в течение определенной недели.

Даты окончания выходных указаны в заголовках столбцов.

Диаграмма

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

В расписании также указаны ключевые даты проекта: альфа-версия, бета-версия и финальная версия.

Рисунок 3. Графическое представление плана поиска дефектов на весь период работы над проектом

Применение

Первый этап начинается со старта проекта и заканчивается выпуском альфа-версии.

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

Еще не все требования реализованы, а то, что сделано, возможно, не будет реализовано в полной мере.

На втором этапе, между альфа- и бета-версиями, кривая растет очень быстро.

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

Перед выпуском бета-версии осталось не так много дефектов.

Наиболее очевидные из них уже найдены и исправлены.

Начинают появляться неочевидные ошибки, которые сложнее найти и исправить.

Кривая замедляется.

А через некоторое время оказываются исправленными и неочевидные ошибки, и кривая перестает расти.

На данный момент выпущена бета-версия программы.

А потом — если новых ошибок не обнаружено — выпускается финальная версия.

К моменту выхода альфа-версии отдел тестирования должен был обнаружить 30% всех дефектов.

К бета-версии должно быть обнаружено 98% всех дефектов.

Управление рисками

Цель

Примечание: В системной инженерии существует методология «анализ режимов и последствий отказов» (англ.

— Fail Modes and Effects Analysis, https://ru.wikipedia.org/wiki/FMEA ).

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

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

Реестр рисков

Цели

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

Нет обмена информацией о типичных ошибках, рисках, решениях.

Нам необходимо вынести все это на всеобщее обозрение и сделать доступным для всей компании.

Примечание (Василина Абу-Навас, бизнес-консультант ассоциации «Практик»): Здесь даже больше: нужно сразу описать решение (по возможности следует найти идеальные решения).

Те.

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

В противном случае риски останутся «граблями».

Пример (Василина Абу-Навас, бизнес-консультант ассоциации «Практик»): Перед нашим Клиентом стояла задача разморозить оборотные средства в размере 25 млн рублей за 1 месяц.

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

Мы составили отличный план по разморозке средств и реализовали его.

В результате мы столкнулись с подоходным налогом.

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

2. Оценить важность каждого риска и вероятность его возникновения.

Пример.

Риск того, что проект будет закрыт из-за падения метеорита на офис компании, имеет большое значение.

Однако вероятность его срабатывания настолько мала, что этот риск можно смело игнорировать.

Пример.

Одна компания, разрабатывающая GPS-навигатор, решила сменить поставщика карт. Причина изменения проста - стоимость лицензии в 2 раза ниже, а формат описания карт тот же.

Однако цена перехода на карты от нового поставщика обошлась компании в 2–3 человеко-года.

Именно столько сил было потрачено на решение возникших технических проблем.

3. Предложите план действий на случай, если риск сработает. Пример.

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

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

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

Каждая такая игра была довольно простой Теги: #Управление проектами #управление временем #управление задачами #управление качеством #управление рисками #управление рисками #управление проектами

• Гершко, Аврам

  19 Oct, 24

• Значение Ppc И Google Insights В Предоставлении Информации Для Вашего Бизнеса

  19 Oct, 24

• Успешные И Опустошенные: Почему Китайские Предприниматели Страдают От Стресса И Неврозов

  19 Oct, 24

• Медиаплеер И Internet Explorer В Windows – Недобросовестная Конкуренция?

  19 Oct, 24

• Синхронизировать Iphone С Google

  19 Oct, 24

• Умная Розетка Redmond Skyplug Rsp-100S Анализ Конструкции И Электрической Схемы. Выявление Недостатков

  19 Oct, 24

• Тестируем Карту «Тройка» С Google Pay — Теперь Даже На Часах?

  19 Oct, 24

• Я Возмущаюсь: Инфобокс!

  19 Oct, 24

• Спящий Режим Для Начинающих

  19 Oct, 24

• Sqlitedog — Современный Менеджер Баз Данных Sqlite.

  19 Oct, 24