Декомпозируй | David Fokin

2023-01-30 01:20:13 Навигация по каналу

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

Итак, темы будут пополняться, но сейчас теги-переходники будут следующие:

#читаем - пост с полезной, иногда не совсем по теме книгой, которую стоит прочитать или послушать. Буду кратко описывать о чем она и делиться впечатлениями. Советую только то, что самому зашло.

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

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

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

А этот пост - #меню, #навигация Открыть/Комментировать

2023-01-25 16:27:38 ​​Как мы планировали спринт и у нас ничего не вышло.

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

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

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

Настал час X, на котором мы расписали бэклог задач, декомпозировали большие задачи и накидали спринт. И все хорошо, скрипт почти готов, он написан и протестирован локально, все задачи и требования соблюдены, ТЗ полностью закрыто в части разработки. 
Перед нами новый этап, промышленное тестирование, стоит оговориться, что этот продукт доставляется на ноутбук через систему управления этих ноутбуков. И вот мы отдали коллегам нашу разработку и начали тестирования, и… ничего не работает. Почему? Как? Зачем? Что не так? Наш скрипт? Появилось много вопросов при отсутствия ответов, при этом мы точно знаем, что проблема не с нашим продуктом. 

Но наш RoadMap был вида:
1. Тестирование функционала на тестовом стенде в промышленной среде
2. Внесение доработок на основании тестирования в промышленной среде
3. Расширение тестовой группы

И вроде все хорошо, у нас есть задача внесения доработок, в которые мы закладывали 4-6 часов правок. Но оказалось что ни коллеги, ни мы не знаем с чем проблема, но проблема точно с системой управления. Не буду тянуть, тестирование и поиск проблему у нас заняло 1.5 месяца непрерывной работы, и наша задача «Внесение доработок на основании тестирования в промышленной среде» растянулась на 5 спринтов.

Казалось, что всё, мы все починили и все работает, но вот проблема, изменения затронули схему согласованную с отделом безопасности и уверенности, что нам согласуют новую схему нет. Родилась новая задача, описать новую схему работы, провести согласования в безами и это еще + 3 недельным спринта.

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

Вот такая грустная история случилась с нашей командой в рамках одного проекта… А дальше мы собрались и пересмотрели наши подходы к задачам. Это в следующем посте.

А как вы декомпозируете ваши задачи? Рады вашим замечаниям и дополнениям в комментариях, ругайте, хвалите, делитесь опытом. Открыть/Комментировать

2023-01-24 17:09:02 ​​Всем привет.

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

Познакомимся с командой?
К сожалению, в связи со спецификой работы и компании я не могу раскрыть все карты, поэтому давайте сформируем нашу команду:
Эджайл Эджайлович
Скрам Скрамович
Канбан Канбанович
и собственно Я, меня вы знаете, а если нет, читайте пост выше.
В команде каждый человек взаимозаменяем, и если один уходит, другой может подхватить 80% его работы, за исключением каких то глубоких экспертных моментов и задач.

Стоит узнать что мы делаем?
Представим, что есть человек, он же пользователь, который использует в своей работе телефон (очень крутой, последний iPhone 17 Pro Max), и у него иногда что то не получается сделать. Этот прекрасный человек идет за решением вопроса, хочет получить услугу, желает избавиться от проблемы.
Так вот, мы ему не помогаем, мы предугадываем что он к нам придет, и делаем так, чтобы проблемы либо совсем не было, либо пользователь решил его сам. Это как ИКЕА, когда ты сам что-то сделал, гордость за себя берет, чувствуешь себя Senior'ом разработки.
А проблем у нас, много, они не кончаются. 
Иногда же, еще приходят к нам другие подобные команды и говорят, помогите нам технически организовать работы по проекту, а иногда приходим и мы для решения какой-то большой задачи.

А теперь о проблемах...
Компания большая, тут есть и безопасники, и архитекторы, структуры, выстроенные процессы и много много всего. И со всеми надо договориться, всех надо уважить или переубедить.
Сегодня мы придумали классную идею, набрали обороты и как в краш-тесте разбились об стену на скорости 60 км/ч. Потом поняли, что не так, переделали и либо пробили стену, либо решили её объехать.
А если кратко, линейной деятельности нет примерно никогда, каждая задача спринта может вылиться в десяток других задач, правила игры меняются, стоп факторы возникают из неоткуда. 
И вот на это все мы натягиваем Scrum.

Как у нас это получается? Будем узнавать далее... Подписывайтесь, критикуйте, давайте советы. Открыть/Комментировать

2023-01-19 16:38:17 Проект.

Что такое проект?
Умная “книга”, на самом деле не книга, а свод знаний, PMBoK (Project Management Body Of Knowledge) дает следующее определение:

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

А если сказать простым языком, проект — это проблема, решенная по расписанию.
Проект ограничен в ресурсах. Даже если у вас есть работа, и вы хотите поехать отдыхать, у вас все равно будут ограничения бюджета. Также вас ограничивает время: в сутках всего 24 часа, хотя для PM, возможно больше. А еще у проекта уникальный результат.

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

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

Четыре этапа проектного мышления:
1. Видим проблему.
2. Продумываем образ будущего без проблемы.
3. Понимаем, какие ресурсы потребуются для достижения этого образа и рассчитываем время.
4. Планируем и действуем.

Итого, подытожим:
• У проекта ограниченные ресурсы, а в конце вас ждет уникальный результат.
• У всех проектов одинаковая структура: начало, планирование, реализация и завершение. На разных этапах нужно разное количество внимания и времени.
• Управлять проектом — значит влиять на результаты, брать на себя ответственность и принимать решения.
• Определитесь, чего именно вы хотите добиться: цель будет отправной точкой вашего проекта. Чем цель конкретнее, тем понятнее, куда вы идете. Если цель трудно сформулировать, то ее можно оставить в виде вектора направления.

Ссылка на Medium Открыть/Комментировать

2023-01-15 14:42:08 ​​Всем привет! 

Кажется, нам стоит познакомиться. Меня зову Давид Фокин, и я являюсь Руководителем направления в одной крупной компании N (Nельзя называть). У меня есть команда, и мы пытаемся сделать жизнь конечного пользователя, а именно сотрудников этой большой компании лучше, работу проще, а возникающих у них проблем меньше. 
Так заведено, что мы не разрабочики, хотя и немного делаем собственные продукты, но любим делать задачи со сроком «вчера», наши проекты могут запуститься вместо конца месяца в середине, этапы меняться по 7-10 раз в день.
Тут, я попытаюсь рассказать, как я применяю инструменты лютейшего PM’а в своих задачах, на своих проектах, и в своей команде. 
Каждый из вас, может дать совет и направить на истинный путь, подискутировать и поделиться опытом!

Будет интересно! Открыть/Комментировать