40 заметок с тегом

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

Позднее Ctrl + ↑

Вот такой получился Kanban

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

У нас определено 5 слоев приоритетности реализации features:

  1. Реализация бизнес-задач, которые приносят выручку/прибыль компании — подключение новых партнеров, типов услуг, ускорение того что должно быть быстрым, снижение лагов.
  2. Реализация задач, которые не дают потерять прибыль компании  — оптимизации, профилактика ошибок, исправление техдолгов, бекапы, резервирование.
  3. То, что влияет на принятие решений — статистика в различных разрезах, отчетность, графики, инструменты аналитики.
  4. Улучшения, которые снижают нагрузку на техническую команду — автоматизация того, что можно, чтобы все кто хочет получить те или иные данные/сборки/отчеты могли их самостоятельно запросить из системы и получить.
  5. Ошибки, улучшения не влияющие на принятие решений — улучшения в веб интерфейсе, скорости работы личного кабинета, добавление мелкой функциональности которая делает работу удобнее.

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

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

И есть одна «красная линия» с высочайшим приоритетом: для задач асап/ критическим багом в продакшене.

Процесс один: беклог -> аналитика -> аналитика готова -> разработка -> разработка готова -> тестирование локально -> кодревью -> тестирование на стеджинге -> тестирование завершено -> выкат на прод -> тестирование на проде -> тесткейсы в вики -> автотест на ui -> внесение в регрессионый план -> завершено.

2016   kanban   Управление проектами

Процесс непрерывного улучшения

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

Чем собственно отличается процесс SCRUM от KANBAN.

Чем меряют сложность задач в Scrum и Kanban

Три графика, которые помогут измерить эффективность всего процесса (от начала до результата)

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

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

Бонусом раскрыли тему о том чем коллектив отличается от команды

А это просто доска с результатами игры. Сначала мы шли медленнее остальных, но за счет того, что автоматизировали многие вещи, ограничили WIP и очередь выиграли.

Что еще интересно, и игру закончили мы Э-э-э раньше двух других команд. Но это, по словам тренеров, не релевантно :)

Могу теперь всем говорить, что у нас не чик-чик и в продакшен, а KANBAN. Даже справка есть.

2015   kanban   Управление проектами
2015   Управление проектами

О приоритетах

Новый вопрос для собеседований:
1) Вовремя
2) работает как надо
3) красивый код
Выберите два из трех.

2015   Собеседование   Управление проектами

Проект, который смог

Три дня назад отправил в продакшен проект, на котором огреб абсолютное количество факапов и фейлов за всю историю своих проектов.

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

10 шагов для планирования проекта

План — ничто, а вот планирование — наше все.

Чтобы выполнить грамотное планирование проекта нужно пройтись по шагам:

  1. Разобраться что это мы вообще делаем, какой-то коробочный продукт, который сами продаем или разработку на заказ, или что-то среднее. От этого могут зависеть приоритеты, подходящая методология.
  2. Определиться с тем, что внутри. Концепция, методология, требования, из которых можно составить понятное описание проекта.
  3. Посмотреть на ограничения: они могут быть по бюджету, технологиям, или по срокам. Если у проекта строгий дедлайн, стоит планировать его от конца к началу.
  4. Провести оценку сложности, временных затрат. Прибегнуть к мнению экспертов, других менеджеров, разработчиков. Посмотреть аналогичные продукты, прикинуть сколько времени может занять реализация подобного. Если времени на оценку много, несколько недель, попробовать спрототипировтаь какие-то элементы конечной системы, замерить сколько на это времени может уходить.
  5. Оформить описание проекта с оценками сроков в виде задач в Диаграме Ганта или например в Product Backlog. Это про способ записать ваши оценки, чтобы потом, в процессе выполнения, их можно было корректировать.
  6. Провести анализ рисков, внести их в список, продумать как будете понимать что риск наступил, как его утилизировать, либо передавать кому-то. Некоторые риски, случаясь, серьезно увеличивают сроки исполнения проекта. Нужно закладывать на реализацию проекта процент времени задержки по каждому риску. Пока вы не занимаетесь управлением рисками, вы находитесь в иллюзии того, что ваши первоначальные оценки верны.
    Регистр рисков в Excel.
  7. Внести в список всех заинтересованных в проекте лиц, их влияние на проект, интерес. Возможно, кто-то из этих людей в списке сам окажется «ходячим риском», а какой-то — ценнейшим ресурсом, который поделится с вами важной информацией либо рисками, о которых вы не подумали.
    Регистр заинтересованных лиц.
  8. Провести ревизию всего что вы напланировали, адекватные ли сроки, изменился ли бюджет, появилась ли потребность в каких-то дополнительных ресурсах?
  9. Внести соответствующие изменения в план.
  10. Поставить себе задачу на отдаленный срок: сохранить полезный опыт из этого проекта. Подойдут любые полезные знания: кусок какого-то плана, реестр рисков, или список лиц, пометки о том, что вам помогло или что подвело, какая методика не подошла, чьим оценкам не стоило доверять. То, что вы унесете с собой как бесценный опыт, и который потом сможете пошарить с другими коллегами.

Рекомендую книгу по управлению рисками Вальсируя с медведями.
И конечно же мастер-классы Stratoplan для всех PM-ов.

2014   Обучение   Управление проектами

О личной эффективности и распорядке дня

Пару недель как изменил распорядок своего дня, и весьма удивлен результатами.
Рабочий день у меня начинается в 5:30: еще во время прогулки с Сэром Лойсо я читаю книгу и составляю список дел. В 7 я в офисе, а к 9:30, когда люди только начинают подтягиваться, 80% всех моих задач уже выполнено, остается дождаться каких-то результатов и совершить несколько телефонных звонков в течение дня, провести пару совещаний.

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

2014   Про себя   Управление проектами

Как вести себя девелоперу загнивающего проекта?

Что делать, если вы разработчик в проекте, который заведомо потерпит крах? Если всё очень плохо, и выхода, кажется, нет? Такой вопрос задал один из пользователей в специальном разделе Stack Exchange. Мы выбрали самые интересные ответы.

Я — разработчик в команде из 5 человек, и я думаю, что наш проект движется к катастрофе. Сейчас объясню, в чём дело, но вопрос вот в чём: как я должен себя вести?

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

Что мне в этом случае делать? Мне работать больше или просто расслабиться? И что сказать менеджеру?

Причины, по которым проект близится к провалу:

  1. Дедлайн скоро, а многие из первостепенных функций ещё не окончены;
  2. Приложение нестабильно и сложно в использовании;
  3. Система очень сложна, в коде трудно разобраться, крайне непросто вносить изменения;
  4. Слишком сложная база данных (более 100 таблиц);
  5. Мутное управление;
  6. Почти никакого автоматизированного или модульного тестирования;
  7. Никаких интеграционных тестов, хотя продукт во многом опирается на сторонние системы.
  8. На самом деле, мы просто унаследовали этот проект вместе с его бардаком пару месяцев назад — до этого над ним работала другая команда во главе с тем же лидером.

Расскажите о своих сомнениях

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

У менеджеров всегда должен быть выбор, что делать; но ваш долг — оценить ситуацию и что-то донести до них. Пошлите email или оставьте записку на столе, если всё катится коту под хвост.

Сделав это, продолжайте работать над проектом с верой в лучшее.

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

Багаж знаний

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

Death March (рус. «Путь камикадзе») — это каноническая книга, которая описывает ущербный управленческий стиль, который широко распространён в сфере разработки программного обеспечения. Из-за сжатия сроков, излишнего усложнения, бесхозяйственности многие проекты плохо заканчивают. Книга помогает понять, что вы не одиноки на этом смертельном марше. Автор Эдвард Йордон классифицирует бесперспективные проекты на 4 категории, в каждой из которых существуют разные стратегии спасения. Иногда единственный выход — просто уйти. Эта книга поможет вам выяснить, какие варианты у вас есть, и узнать, что вы можете или не можете сделать.

Catastrophe Disentanglement написана больше для менеджеров проектов. Она нацелена на то, чтобы помочь отсортировать подорванный проект: что нужно убрать, что нужно вернуть, как донести это до потребителей. «Традиционное» управление проектами часто приводит нас в тупик, и мы не сможем выбраться из него, пользуясь теми же методами. Эту книгу несколько труднее читать, чем «Путь камикадзе», но очень неплохо иметь её на книжной полке.

Останьтесь там же, но имейте варианты

  1. Работайте много, но не в ущерб семье или здоровью;
  2. Записывайте все критичные решения, особенно если они касаются вашей работы;
  3. Продолжайте налаживать связи и имейте несколько запасных вариантов, если ситуация станет слишком сложной или вы станете жертвой массовых увольнений;
  4. Попытайтесь не расценивать свой проект как провалившийся. Всем нравятся люди, которые сохраняют хороший настрой и продолжают бороться перед лицом судьбы. Так что оставайтесь таким человеком так долго, насколько это возможно. На рабочем месте всегда хороши боевой дух, мужество и решительность.
  5. Если вы предчувствуете провал проекта, значит, вы предчувствуете и разбор полётов. И там каждого настигнет ответственность. Приготовьтесь защищать весь свой код. (К слову, всегда пишите код понятно, чтоб потом проще было за него отчитываться). Если у вас есть письма или фрагменты ТЗ, которые повлияли на ваши действия, тем лучше.
  6. На этом разборе полётов сохраняйте бодрый настрой и обоснованно отмазывайтесь, если вас призовут к ответу.

Источник:
Как вести себя девелоперу загнивающего проекта — Цукерберг Позвонит

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

Черная книга менеджера

Год или полтора уже рассылаю знакомым книгу Славы Панкратова «Черная книга менеджера», в которой доступным языком, даже с матюками, рассказывается, в чем же заключается работа менеджера проектов, и как быть эффективным менеджером проектов. Очень рекомендую всем тимлидам и проджект-менеджерам для просветления.

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

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

2013   Книги   Управление проектами
Ранее Ctrl + ↓