#знания
Новая версия Scrum guide
2 недели назад анонсировали новую версию Скрам гайда. За 25 лет существования фреймворка, он менялся всего несколько раз и каждый раз это большое событие в мире Эджайла.
Следуя тренду последних лет, Cкрам стал более инклюзивным. Из гайда убрали слова тестирование, релиз, система, характерные для мира разработки софта. Людей из других сфер, которые только пробуют фреймворк, отталкивали эти термины, мол "у нас такого нет, поэтому Скрам нам не подходит". По этой причине их заменили на более нейтральные 🤐.
Сам текст будто бы прогнали через сервис glvrd.ru - он сократился с 19 страниц до 13, став менее формальным и более дружелюбным.
В этом же и минус новой редакции - общие фразы не объясняют как именно использовать Скрам. Например, в Sprint Review раньше были конкретные советы как проводить митинг: проходиться по done, обсуждать ситуацию на рынке, релизы, бюджеты. Теперь все это упразднили.
❗В новой версии есть одно действительно важное обновление.
Раньше у команды была только Sprint Goal - микро-цель на ближайшие 2 недели. Теперь все микро-цели собираются в одну большую-мега-цель Product Goal, ради которой все затевалось. Такая цель очень нужна продактам, потому что помогает ответить на вечные вопросы "какой продукт мы строим и для кого?", на которых потом строится весь продакт-менеджмент.
Изменений в новом гайде много (полный список), но большинство из них косметические - это все тот же старый добрый Скрам.
Текст: Роман Ковалевский
Новая версия Scrum guide
2 недели назад анонсировали новую версию Скрам гайда. За 25 лет существования фреймворка, он менялся всего несколько раз и каждый раз это большое событие в мире Эджайла.
Следуя тренду последних лет, Cкрам стал более инклюзивным. Из гайда убрали слова тестирование, релиз, система, характерные для мира разработки софта. Людей из других сфер, которые только пробуют фреймворк, отталкивали эти термины, мол "у нас такого нет, поэтому Скрам нам не подходит". По этой причине их заменили на более нейтральные 🤐.
Сам текст будто бы прогнали через сервис glvrd.ru - он сократился с 19 страниц до 13, став менее формальным и более дружелюбным.
В этом же и минус новой редакции - общие фразы не объясняют как именно использовать Скрам. Например, в Sprint Review раньше были конкретные советы как проводить митинг: проходиться по done, обсуждать ситуацию на рынке, релизы, бюджеты. Теперь все это упразднили.
❗В новой версии есть одно действительно важное обновление.
Раньше у команды была только Sprint Goal - микро-цель на ближайшие 2 недели. Теперь все микро-цели собираются в одну большую-мега-цель Product Goal, ради которой все затевалось. Такая цель очень нужна продактам, потому что помогает ответить на вечные вопросы "какой продукт мы строим и для кого?", на которых потом строится весь продакт-менеджмент.
Изменений в новом гайде много (полный список), но большинство из них косметические - это все тот же старый добрый Скрам.
Текст: Роман Ковалевский
Это был очень трудный год, но, несмотря на это, я уверен, мы сделали много замечательных вещей в нем.
Я желаю вам сильных показателей, энтузиазма для вас и вашей команды (если она есть), преодоления препятствий на пути, и много счастливых моментов.
В свою очередь, очень надеюсь, что добью подготовленный пост и буду публиковать посты чаще. Но адаптация в другой стране меня поглотила... Оказалось, много хлопот. Тем не менее, я — самурай, у которого нет цели, у него есть только путь.
Спасибо, что читаете мои заметки и реагируете на них. Я ценю это. С Новым Годом тебя, который читает это сообщение, и твоих близких! 🥳🎅🏻🎄
Я желаю вам сильных показателей, энтузиазма для вас и вашей команды (если она есть), преодоления препятствий на пути, и много счастливых моментов.
В свою очередь, очень надеюсь, что добью подготовленный пост и буду публиковать посты чаще. Но адаптация в другой стране меня поглотила... Оказалось, много хлопот. Тем не менее, я — самурай, у которого нет цели, у него есть только путь.
Спасибо, что читаете мои заметки и реагируете на них. Я ценю это. С Новым Годом тебя, который читает это сообщение, и твоих близких! 🥳🎅🏻🎄
ЧАСТЬ 1
Наконец я проснулся от релокационного сна.😃 Хоть и есть небольшая “сонливость”🤤.
Сперва объясню, почему можно назвать проект успешным, если он превысил срок разработки вдвое, а бюджет в 3 раза, при этом, на выходе мы получили уникальный, качественный и очень крутой продукт. Выше я публиковал треугольник PMI. Этот треугольник позволяет понять наглядно, какой результат мы можем получить: сфокусировавшись на цене и времени или на цене и скоупе, или скоупе и времени — мы можем получить качественный продукт. Но практическивсегда никогда мы не получим качественный продукт, если попытаемся сфокусироваться на приемлемой цене за разработку, приемлемом тайминге и не огромном и понятном скоупе работ. Это, можно сказать, аксиома, в жизни это не работает. Опустим единичные случаи. Поэтому, исходя из этих данных, мы можем назвать наш проект успешным. В жизни же, этот проект может оказаться неуспешным, потому что заказчик так посчитает. Но тут уже зависит от изначальных требований и Acceptance Criteria. Кстати, позже об этом поговорим, как и о DoR, DoD.
#знания
Устав проекта/Резюме проекта/План управления проектом
Это документ, который формализует ключевые договоренности по всем измерениям проекта между его участниками, содержащий сведения о сфере деятельности, целях и участниках проекта. Он разрабатывается в ходе инициации проекта – до решения о его начале.
PMBoK говорит: «Устав проекта — это документ, выпускаемый инициатором или спонсором проекта, который формально авторизует существование проекта и предоставляет руководителю проекта полномочия использовать ресурсы организации в операциях проекта. Он документирует бизнес-потребности, допущения, ограничения, понимание потребностей заказчика, высокоуровневые требования, а также новый продукт, услугу или результат, который планируется создать.»
Из чего он состоит:
● Значение проекта;
● Измеримые цели проекта и соответствующие критерии успеха;
● Высокоуровневые требования;
● Высокоуровневые описания, границы и ключевые поставляемые результаты проекта;
● Совокупный риск проекта;
● Укрупненное расписание контрольных событий;
● Заранее утвержденные финансовые ресурсы;
● Список основных заинтересованных сторон;
● Требования к одобрению проекта;
● Критерии выхода из проекта;
● Назначенный руководитель проекта, сфера ответственности и уровень полномочий;
● Участники проекта.
Если необходимо изменить зафиксированное в Уставе, значит для ПМ или Исполнителя это повод к пересмотру договорных отношений с Заказчиком. Соответственно этот документ делает Заказчик или Спонсор, а не ПМ или Исполнитель. Это важно!
Шаблон адекватного Устава проекта прикрепляю здесь.
Устав не обязательно создается. Вместо него может быть договор, в котором будут прописаны все необходимые условия. Также, есть резюме проекта. Это схожие по сути документы, но все-таки отличаются. Он может быть более коротким.
Резюме проекта помогает определиться с дальнейшими шагами, найти понимание с командой и заказчиком. Проекты без резюме часто проваливаются, потому что каждый участник видит проект по-своему, и в итоге появляется много нестыковок. Если спонсор проекта не сделал резюме, это может сделать менеджер. Но обязательно получите обратную связь от спонсора, чтобы потом не оказалось, что вы понимаете проект совершенно по-разному.
Итак, предположим нам нужно подготовить резюме проекта.
На этом шаге нужно определиться, что из себя представляет проект.
Спонсор проекта готовит простой одностраничный документ — резюме проекта, в котором отвечает на несколько вопросов:
Цель проекта — какой продукт, услугу или результат нужно получить? (лучше сформулировать по SMART);
Выгоды — зачем мы это делаем?
Какие материальные/нематериальные ценности мы получим от проекта?
Требования — без каких условий проект/результат проекта не имеет смысла?
Сроки — сколько это займёт времени?
Бюджет — сколько это будет стоить?
Риски — что может пойти не так? Какие неопределённые события могут поставить проект под угрозу?
Роли — кто будет принимать участие в проекте?
Потом резюме можно править и расширять — этим займётся менеджер проекта.
Наконец я проснулся от релокационного сна.😃 Хоть и есть небольшая “сонливость”🤤.
Сперва объясню, почему можно назвать проект успешным, если он превысил срок разработки вдвое, а бюджет в 3 раза, при этом, на выходе мы получили уникальный, качественный и очень крутой продукт. Выше я публиковал треугольник PMI. Этот треугольник позволяет понять наглядно, какой результат мы можем получить: сфокусировавшись на цене и времени или на цене и скоупе, или скоупе и времени — мы можем получить качественный продукт. Но практически
#знания
Устав проекта/Резюме проекта/План управления проектом
Это документ, который формализует ключевые договоренности по всем измерениям проекта между его участниками, содержащий сведения о сфере деятельности, целях и участниках проекта. Он разрабатывается в ходе инициации проекта – до решения о его начале.
PMBoK говорит: «Устав проекта — это документ, выпускаемый инициатором или спонсором проекта, который формально авторизует существование проекта и предоставляет руководителю проекта полномочия использовать ресурсы организации в операциях проекта. Он документирует бизнес-потребности, допущения, ограничения, понимание потребностей заказчика, высокоуровневые требования, а также новый продукт, услугу или результат, который планируется создать.»
Из чего он состоит:
● Значение проекта;
● Измеримые цели проекта и соответствующие критерии успеха;
● Высокоуровневые требования;
● Высокоуровневые описания, границы и ключевые поставляемые результаты проекта;
● Совокупный риск проекта;
● Укрупненное расписание контрольных событий;
● Заранее утвержденные финансовые ресурсы;
● Список основных заинтересованных сторон;
● Требования к одобрению проекта;
● Критерии выхода из проекта;
● Назначенный руководитель проекта, сфера ответственности и уровень полномочий;
● Участники проекта.
Если необходимо изменить зафиксированное в Уставе, значит для ПМ или Исполнителя это повод к пересмотру договорных отношений с Заказчиком. Соответственно этот документ делает Заказчик или Спонсор, а не ПМ или Исполнитель. Это важно!
Шаблон адекватного Устава проекта прикрепляю здесь.
Устав не обязательно создается. Вместо него может быть договор, в котором будут прописаны все необходимые условия. Также, есть резюме проекта. Это схожие по сути документы, но все-таки отличаются. Он может быть более коротким.
Резюме проекта помогает определиться с дальнейшими шагами, найти понимание с командой и заказчиком. Проекты без резюме часто проваливаются, потому что каждый участник видит проект по-своему, и в итоге появляется много нестыковок. Если спонсор проекта не сделал резюме, это может сделать менеджер. Но обязательно получите обратную связь от спонсора, чтобы потом не оказалось, что вы понимаете проект совершенно по-разному.
Итак, предположим нам нужно подготовить резюме проекта.
На этом шаге нужно определиться, что из себя представляет проект.
Спонсор проекта готовит простой одностраничный документ — резюме проекта, в котором отвечает на несколько вопросов:
Цель проекта — какой продукт, услугу или результат нужно получить? (лучше сформулировать по SMART);
Выгоды — зачем мы это делаем?
Какие материальные/нематериальные ценности мы получим от проекта?
Требования — без каких условий проект/результат проекта не имеет смысла?
Сроки — сколько это займёт времени?
Бюджет — сколько это будет стоить?
Риски — что может пойти не так? Какие неопределённые события могут поставить проект под угрозу?
Роли — кто будет принимать участие в проекте?
Потом резюме можно править и расширять — этим займётся менеджер проекта.
#знания
ЧАСТЬ 2
К сожалению, из-за ограничения в символах пришлось разбить текст на две части.
Шаблон Резюме проекта можете скачать здесь.
Есть еще план управления проектом. Его иногда путают/объединяют с уставом проекта, но это неверно.
PMBoK говорит: «План управления проектом — это документ, описывающий, как проект будет исполняться, как будет происходить его мониторинг и контроль. Он интегрирует и консолидирует все вспомогательные и базовые планы, полученные в результате процессов планирования.»
Устав более статичен. План управления проектом говорит о том, как ПМ и команда проекта будут исполнять и контролировать этот проект, чтобы добиться результатов в границах и параметрах, описанных в Уставе. Этот документ более динамичен, он изменчив по ходу проекта, так как сразу определить все процессы не удастся.
Спасибо всем, кто читает и ждет. В следующий раз поделюсь своим фидбэком из работы в Эмиратах. 😉
ЧАСТЬ 2
К сожалению, из-за ограничения в символах пришлось разбить текст на две части.
Шаблон Резюме проекта можете скачать здесь.
Есть еще план управления проектом. Его иногда путают/объединяют с уставом проекта, но это неверно.
PMBoK говорит: «План управления проектом — это документ, описывающий, как проект будет исполняться, как будет происходить его мониторинг и контроль. Он интегрирует и консолидирует все вспомогательные и базовые планы, полученные в результате процессов планирования.»
Устав более статичен. План управления проектом говорит о том, как ПМ и команда проекта будут исполнять и контролировать этот проект, чтобы добиться результатов в границах и параметрах, описанных в Уставе. Этот документ более динамичен, он изменчив по ходу проекта, так как сразу определить все процессы не удастся.
Спасибо всем, кто читает и ждет. В следующий раз поделюсь своим фидбэком из работы в Эмиратах. 😉
#мойстатус #знания
Я не знал, что меня ждет❗️(часть 1)
До приезда в Эмираты я не знал, что меня ждет. А когда приехал, я увидел другие законы, мультинациональность, другие правила и систему, отношение к работе и т.п., отличные от наших беларусских реалий. Да даже в Украине и России не так. Все, что написал выше, всё другое. Но давайте по порядку.
1️⃣ Компания — аутсорсинговая, хотя иногда мы разрабатываем собственный продукт для продажи.
2️⃣ Смена топ-менеджмента на более молодой и прогрессивный
Это отразилось и на моей роли. Например, приходится заниматься некоторыми вещами, отличными от проектного менеджмента. Ну как приходится, это моя инициатива, т.к. я вижу, что можно улучшить некоторые процессы, которые могут поспособствовать развитию компании и улучшить работу на проектах. Скажем так, создание внутренних правил и полисов (дополнение к текущим или полностью создание нового). А так как я работаю непосредственно с командой разработчиков, то, преимущественно, речь идет о них. Опыт в этом мне не помешает. Особенно, если я могу внести вклад в развитие компании — вдвойне удовольствие и пару строчек в резюме 🙂.
3️⃣ Знакомство
Я созвал встречу в meeting room, предварительно подготовив материал и тему встречи.
Суть: каждый по кругу коротко рассказывает о себе пару фактов: как зовут, позиция в разработке, откуда родом, хобби, и своя уникальная особенность. Я не записывал на бумагу, я решил записать на диктофон, предварительно спросив ребят разрешение. Да, о себе я тоже рассказал, разумеется.
После я адаптировал тест Майерс-Бриггс для ребят и сбросил всем шаблон, рассказав суть теста и обозначив сроки выполнения.
Для чего это было нужно. Некоторые факты дадут нужную мне информацию о человеке, а заодно некоторые ребята узнают факты о своих коллегах. Вероятно, что не все так хорошо знакомы и знают о хобби друг друга и уникальных особенностях. А тест — это больше прикладная тема, которая может примерно показать, какой у кого тип личности (отсылка на книгу Патрика Ленсиони — 5 пороков команды).
4️⃣ Разработчиков пока немного (есть еще удаленная команда), а проектов столько, что не хватает людей. Либо если бы было времени больше, то было бы терпимо. Это плохая практика, когда некоторые разработчики работают параллельно на нескольких проектах. И это проблема: жонглирование человеческими ресурсами и временем, чтобы максимально безболезненно закрыть проекты. К сожалению, такое счастье мне досталось от предыдущего менеджмента. Но мы всё пофиксим! Вопрос времени.
5️⃣ Разработчики давно не были в отпуске
Как все знают, утомление и выгорание может быть ближе, чем мы думаем. К сожалению, отпустить даже одного в отпуск не представляется возможным, поэтому я решил, что можно хотя бы укрепить моральное состояние ребят — развитие в корпоративной культуре. Например, с ходу сделал раз в две недели Pizza Day, т.к. этого у них не было. Я был удивлен их радостным лицам, когда ребята могли отвлечься, пожевать их любимую пиццу и поговорить на разные темы. Мелочь, но работает. Также, я начал хвалить ребят за работу, которую они сделали хорошо, в срок, проявили инициативу и т.д. И это работает! Оплачиваемые овертаймы. Раньше с этим были проблемы.
6️⃣ Не настроены процессы в разработке
Scrum, Kanban, Waterfall, XP... Не, не слышали! Нельзя просто так взять и вслепую начать внедрять Скрам, Канбан или какую-то другую методологию. Есть много факторов, позволяющих понять, что лучше применить (есть еще способ испробовать разные подходы), но это уже другая история. Так как компания работает преимущественно с гос. учреждениями, то тут Scrum может не покатить. Канбан — менее регламентирован (разве что инструмент доски покатит). Пришлось пойти ва-банк — создать свой легковесный фреймворк (это громко сказано) лишь с пару обязательными ритуалами, техниками и подходами. Он чем-то похож на легковесный, гибкий фреймворк p3express. Кстати, мне он очень нравится. Я уже об этом говорил ранее. Легкий в понимании, простой в использовании. Но натренироваться нужно (сам еще в процессе).
Я не знал, что меня ждет❗️(часть 1)
До приезда в Эмираты я не знал, что меня ждет. А когда приехал, я увидел другие законы, мультинациональность, другие правила и систему, отношение к работе и т.п., отличные от наших беларусских реалий. Да даже в Украине и России не так. Все, что написал выше, всё другое. Но давайте по порядку.
1️⃣ Компания — аутсорсинговая, хотя иногда мы разрабатываем собственный продукт для продажи.
2️⃣ Смена топ-менеджмента на более молодой и прогрессивный
Это отразилось и на моей роли. Например, приходится заниматься некоторыми вещами, отличными от проектного менеджмента. Ну как приходится, это моя инициатива, т.к. я вижу, что можно улучшить некоторые процессы, которые могут поспособствовать развитию компании и улучшить работу на проектах. Скажем так, создание внутренних правил и полисов (дополнение к текущим или полностью создание нового). А так как я работаю непосредственно с командой разработчиков, то, преимущественно, речь идет о них. Опыт в этом мне не помешает. Особенно, если я могу внести вклад в развитие компании — вдвойне удовольствие и пару строчек в резюме 🙂.
3️⃣ Знакомство
Я созвал встречу в meeting room, предварительно подготовив материал и тему встречи.
Суть: каждый по кругу коротко рассказывает о себе пару фактов: как зовут, позиция в разработке, откуда родом, хобби, и своя уникальная особенность. Я не записывал на бумагу, я решил записать на диктофон, предварительно спросив ребят разрешение. Да, о себе я тоже рассказал, разумеется.
После я адаптировал тест Майерс-Бриггс для ребят и сбросил всем шаблон, рассказав суть теста и обозначив сроки выполнения.
Для чего это было нужно. Некоторые факты дадут нужную мне информацию о человеке, а заодно некоторые ребята узнают факты о своих коллегах. Вероятно, что не все так хорошо знакомы и знают о хобби друг друга и уникальных особенностях. А тест — это больше прикладная тема, которая может примерно показать, какой у кого тип личности (отсылка на книгу Патрика Ленсиони — 5 пороков команды).
4️⃣ Разработчиков пока немного (есть еще удаленная команда), а проектов столько, что не хватает людей. Либо если бы было времени больше, то было бы терпимо. Это плохая практика, когда некоторые разработчики работают параллельно на нескольких проектах. И это проблема: жонглирование человеческими ресурсами и временем, чтобы максимально безболезненно закрыть проекты. К сожалению, такое счастье мне досталось от предыдущего менеджмента. Но мы всё пофиксим! Вопрос времени.
5️⃣ Разработчики давно не были в отпуске
Как все знают, утомление и выгорание может быть ближе, чем мы думаем. К сожалению, отпустить даже одного в отпуск не представляется возможным, поэтому я решил, что можно хотя бы укрепить моральное состояние ребят — развитие в корпоративной культуре. Например, с ходу сделал раз в две недели Pizza Day, т.к. этого у них не было. Я был удивлен их радостным лицам, когда ребята могли отвлечься, пожевать их любимую пиццу и поговорить на разные темы. Мелочь, но работает. Также, я начал хвалить ребят за работу, которую они сделали хорошо, в срок, проявили инициативу и т.д. И это работает! Оплачиваемые овертаймы. Раньше с этим были проблемы.
6️⃣ Не настроены процессы в разработке
Scrum, Kanban, Waterfall, XP... Не, не слышали! Нельзя просто так взять и вслепую начать внедрять Скрам, Канбан или какую-то другую методологию. Есть много факторов, позволяющих понять, что лучше применить (есть еще способ испробовать разные подходы), но это уже другая история. Так как компания работает преимущественно с гос. учреждениями, то тут Scrum может не покатить. Канбан — менее регламентирован (разве что инструмент доски покатит). Пришлось пойти ва-банк — создать свой легковесный фреймворк (это громко сказано) лишь с пару обязательными ритуалами, техниками и подходами. Он чем-то похож на легковесный, гибкий фреймворк p3express. Кстати, мне он очень нравится. Я уже об этом говорил ранее. Легкий в понимании, простой в использовании. Но натренироваться нужно (сам еще в процессе).
#мойстатус #знания
Я не знал, что меня ждет❗️(часть 2)
7️⃣ Инструменты и рабочие тулы
Jira, Confluence, Gitlab, Google Docs — нет! Тут этого не было. Slack и Bitbucket только были. И то, не особо ими и пользовались. Ребята юзали Azure DevOps, в котором у меня не было опыта от слова вообще, MS Teams, Office 365, в который входят различные продукты и сервисы от Microsoft (там же и почта Outlook, которую используем как оф. канал общения с клиентами), виртуальная машина — всё связано с Microsoft.
Поясню. Здесь в Эмиратах всё секьюрно, и местные власти предпочитают Microsoft (офис который у нас тут есть) Гугловским сервисам, секьюрность которых, кстати, чуть пониже Гейтсовских. Поэтому работа с отдельными файлами — это норма. И файлы грузятся в онлайн облако — OneDrive. Сбрасывать клиентам документацию не ссылкой на файл, а отдельным файлом. Да, вот так вот 🙂. Напомнило мне, когда я работал в банке, и бразуером пользовались Internet Explorer (до того, как он стал Edge). Приходится привыкать и адаптироваться.
Но нужно было как-то улучшить это положение. Что сделал я:
Создал пространство в Google Drive для компании, настроил, чтобы было удобно работать с файлами, покрутил настройки безопасности, дал доступы нашему менеджменту и разработчикам. Этот вариант был только для нашей компании. Но хоть как-то упростить работу.
Создали пространства компании в Jira и Confluence (как не крути, Jira удобнее и функциональнее Azure, а в Confluence удобнее хранить документацию о проектах в виде архива. Тем паче эти две тулы одной компании, секьюрность которой высокая).
Также, создал Time reports и обучил разработчиков корректно его оформлять. Один проект = один Time report. Но так как некоторые разработчики работали на нескольких проектах одновременно, пришлось один отчет создать общим, в котором они писали каждый день, каким проектом занимались, что именно делали и указывали количество часов, затраченных на работу. В дальнейшем, кстати, время трекать будем иначе, более точно, т.к. разработчики могут указать не реальные часы. Все это нужно для того, чтобы менеджмент понимал прозрачность работы и мог корректно считать зарплату, но и другие выплаты.
8️⃣ Митинги
Как я писал выше, соотношение разработчиков к проектам + малые сроки на некоторых проектах были проблемой. А в одном проекте настолько жесткий дедлайн, что частота встреч только отнимала бы время разработки и это реально боль. Взвесив все за и против, я решил внедрить только самые важные события: спринт (у нас недельный), стендап (раз-два в неделю), ретроспектива (раз неделю/две), PBR (это когда пересмотр бэклога и его наполнение — раз в неделю). Всё! И это работает. Демо не на всех проектах присутствует. Вероятно, такие взаимодействия с заказчиками были налажены до меня. Но на одном проекте, где заказчик не из гос. аппарата, я настраиваю процессы по канонам всеми нам знакомым практикам и использую нормальные подходы. Чего только стоит консолидация из требований задач и их эстимация (оценка) в соответствии с известными практиками. Разумеется и демо там есть.
9️⃣ Скорость работы, знания и взаимодействие
Буду краток, скорость работы пониже и знания похуже наших разрабов. Тут ничего не поделаешь. Однако взаимодействие в некоторых местах полегче будет, ребята тебя больше слушают и меньше включают своё эго, которое у нас раздуто в разы по сравнению с этими ребятами. Стоило бы поучиться.
Есть и слабая сторона — это отношение к работе: исполнительность, ответственность и упорство. По сравнению с русскоговорящими разработчиками эти качества страдают. Я уже не говорю про западных ребят (там эти качества чаще выше, чем у русскоговорящих программистов).
В общем, Восток, такой Восток. Тут нужен другой подход. Но не всегда и другой подход поможет. Если ты не завоевал сердце ребят и не заслужил доверие — считай, что расположить ребят не получится и ты будешь заниматься микроменеджментом.
Это основные моменты, над которыми нужно работать. Работы хватает более чем. Скоро грядут изменения в виде подкрепления человеческих ресурсов. Надеюсь, это положительно отразится на работе.
Я не знал, что меня ждет❗️(часть 2)
7️⃣ Инструменты и рабочие тулы
Jira, Confluence, Gitlab, Google Docs — нет! Тут этого не было. Slack и Bitbucket только были. И то, не особо ими и пользовались. Ребята юзали Azure DevOps, в котором у меня не было опыта от слова вообще, MS Teams, Office 365, в который входят различные продукты и сервисы от Microsoft (там же и почта Outlook, которую используем как оф. канал общения с клиентами), виртуальная машина — всё связано с Microsoft.
Поясню. Здесь в Эмиратах всё секьюрно, и местные власти предпочитают Microsoft (офис который у нас тут есть) Гугловским сервисам, секьюрность которых, кстати, чуть пониже Гейтсовских. Поэтому работа с отдельными файлами — это норма. И файлы грузятся в онлайн облако — OneDrive. Сбрасывать клиентам документацию не ссылкой на файл, а отдельным файлом. Да, вот так вот 🙂. Напомнило мне, когда я работал в банке, и бразуером пользовались Internet Explorer (до того, как он стал Edge). Приходится привыкать и адаптироваться.
Но нужно было как-то улучшить это положение. Что сделал я:
Создал пространство в Google Drive для компании, настроил, чтобы было удобно работать с файлами, покрутил настройки безопасности, дал доступы нашему менеджменту и разработчикам. Этот вариант был только для нашей компании. Но хоть как-то упростить работу.
Создали пространства компании в Jira и Confluence (как не крути, Jira удобнее и функциональнее Azure, а в Confluence удобнее хранить документацию о проектах в виде архива. Тем паче эти две тулы одной компании, секьюрность которой высокая).
Также, создал Time reports и обучил разработчиков корректно его оформлять. Один проект = один Time report. Но так как некоторые разработчики работали на нескольких проектах одновременно, пришлось один отчет создать общим, в котором они писали каждый день, каким проектом занимались, что именно делали и указывали количество часов, затраченных на работу. В дальнейшем, кстати, время трекать будем иначе, более точно, т.к. разработчики могут указать не реальные часы. Все это нужно для того, чтобы менеджмент понимал прозрачность работы и мог корректно считать зарплату, но и другие выплаты.
8️⃣ Митинги
Как я писал выше, соотношение разработчиков к проектам + малые сроки на некоторых проектах были проблемой. А в одном проекте настолько жесткий дедлайн, что частота встреч только отнимала бы время разработки и это реально боль. Взвесив все за и против, я решил внедрить только самые важные события: спринт (у нас недельный), стендап (раз-два в неделю), ретроспектива (раз неделю/две), PBR (это когда пересмотр бэклога и его наполнение — раз в неделю). Всё! И это работает. Демо не на всех проектах присутствует. Вероятно, такие взаимодействия с заказчиками были налажены до меня. Но на одном проекте, где заказчик не из гос. аппарата, я настраиваю процессы по канонам всеми нам знакомым практикам и использую нормальные подходы. Чего только стоит консолидация из требований задач и их эстимация (оценка) в соответствии с известными практиками. Разумеется и демо там есть.
9️⃣ Скорость работы, знания и взаимодействие
Буду краток, скорость работы пониже и знания похуже наших разрабов. Тут ничего не поделаешь. Однако взаимодействие в некоторых местах полегче будет, ребята тебя больше слушают и меньше включают своё эго, которое у нас раздуто в разы по сравнению с этими ребятами. Стоило бы поучиться.
Есть и слабая сторона — это отношение к работе: исполнительность, ответственность и упорство. По сравнению с русскоговорящими разработчиками эти качества страдают. Я уже не говорю про западных ребят (там эти качества чаще выше, чем у русскоговорящих программистов).
В общем, Восток, такой Восток. Тут нужен другой подход. Но не всегда и другой подход поможет. Если ты не завоевал сердце ребят и не заслужил доверие — считай, что расположить ребят не получится и ты будешь заниматься микроменеджментом.
Это основные моменты, над которыми нужно работать. Работы хватает более чем. Скоро грядут изменения в виде подкрепления человеческих ресурсов. Надеюсь, это положительно отразится на работе.
#мойстатус #горькаяправда #инсайты
Все проекты закрылись! 😲
Пандемия очень забавная штука. Мы не отрицаем, что это плохо с точки зрения безопасности нашего здоровья, это ограничения в передвижении географически, ряд ограничений, мешающих делать вещи, которые можно было делать раньше без проблем и т.д. Но и рынок, вроде бы, оживился, так как бизнесы либо адаптируются к текущим реалиям и налаживают свои бизнес-процессы на дистанционный формат типа удаленной работы сотрудников и взаимодействие с клиентом, либо не налаживают и “погибают”.
В случае с моей компанией пандемия ударила ниже пояса. Казалось бы. Выяснилось, что компания терпит большие убытки. Поэтому топами было решено закрыть все текущие проекты, сократить большинство сотрудников, некоторых перераспределить. А еще, относительно недавно, инвестором была куплена другая украинская ИТ-галера - головной офис расположен в Абу-Даби - которая войдет в нашу. Некий вирджиновский конгломерат, блин. Что из этого выйдет, я догадываюсь. Но я понимаю, что дело запахло жареным.
Ситуация была в подвешенном состоянии. Договорился с руководством. Начал потихоньку присматривать новые места. Дабы не было затратно по деньгам, я принял непростое для себя решение вернуться в Минск, хотя я мог остаться там. Быть на связи и работать удаленно сейчас вообще не проблема, ну а я сэкономлю на аренде, еде и прочих затратных статьях. Дубай ведь город дорогой :)
Вот она голая правда, без прекрас и подоплеки. Но это не конец. В жизни часто бывают взлеты и падения. Отчаиваться точно не стоит. Моя предприимчивая, волевая натура и в этот раз помогла мне выиграть, а не проиграть. Я неплохо заработал, несмотря на то, что Дубай дорогой, подтянул свой английский, обзавелся связями и друзьями, мое резюме уже стОит дороже, чем раньше, да и границ больше открылось.
Подтвержденный инсайд
Всегда придерживался этой политики и придерживаюсь сейчас: что бы ни случилось, я всегда рекомендую налаживать хорошие взаимоотношения с людьми, несмотря на негативный исход. Потому что репутация в работе - чуть ли не самый важный элемент. Сейчас тебе все равно, а спустя какое-то время судьба тебя сведёт с твоими бывшими коллегами в другом месте. И в каких отношениях ты с ними был раньше, будет определять твой будущий результат. Ну или не результат. It’s up to you.
P.S. Несмотря на то, что это мои заметки, следующий пост я продолжу по теме менеджмента. Киньте реакций, если читаете меня. Мне будет приятно.
Все проекты закрылись! 😲
Пандемия очень забавная штука. Мы не отрицаем, что это плохо с точки зрения безопасности нашего здоровья, это ограничения в передвижении географически, ряд ограничений, мешающих делать вещи, которые можно было делать раньше без проблем и т.д. Но и рынок, вроде бы, оживился, так как бизнесы либо адаптируются к текущим реалиям и налаживают свои бизнес-процессы на дистанционный формат типа удаленной работы сотрудников и взаимодействие с клиентом, либо не налаживают и “погибают”.
В случае с моей компанией пандемия ударила ниже пояса. Казалось бы. Выяснилось, что компания терпит большие убытки. Поэтому топами было решено закрыть все текущие проекты, сократить большинство сотрудников, некоторых перераспределить. А еще, относительно недавно, инвестором была куплена другая украинская ИТ-галера - головной офис расположен в Абу-Даби - которая войдет в нашу. Некий вирджиновский конгломерат, блин. Что из этого выйдет, я догадываюсь. Но я понимаю, что дело запахло жареным.
Ситуация была в подвешенном состоянии. Договорился с руководством. Начал потихоньку присматривать новые места. Дабы не было затратно по деньгам, я принял непростое для себя решение вернуться в Минск, хотя я мог остаться там. Быть на связи и работать удаленно сейчас вообще не проблема, ну а я сэкономлю на аренде, еде и прочих затратных статьях. Дубай ведь город дорогой :)
Вот она голая правда, без прекрас и подоплеки. Но это не конец. В жизни часто бывают взлеты и падения. Отчаиваться точно не стоит. Моя предприимчивая, волевая натура и в этот раз помогла мне выиграть, а не проиграть. Я неплохо заработал, несмотря на то, что Дубай дорогой, подтянул свой английский, обзавелся связями и друзьями, мое резюме уже стОит дороже, чем раньше, да и границ больше открылось.
Подтвержденный инсайд
Всегда придерживался этой политики и придерживаюсь сейчас: что бы ни случилось, я всегда рекомендую налаживать хорошие взаимоотношения с людьми, несмотря на негативный исход. Потому что репутация в работе - чуть ли не самый важный элемент. Сейчас тебе все равно, а спустя какое-то время судьба тебя сведёт с твоими бывшими коллегами в другом месте. И в каких отношениях ты с ними был раньше, будет определять твой будущий результат. Ну или не результат. It’s up to you.
P.S. Несмотря на то, что это мои заметки, следующий пост я продолжу по теме менеджмента. Киньте реакций, если читаете меня. Мне будет приятно.
#мойстатус
Всем Алоха!🖖🏻
Еще находясь в Дубае, я уже начал присматривать новое место работы. На данный момент пройдено около 22-23 интервью (именно взаимодействие от отклика/переписки с рекрутером до технического интервью). Итого - 1 оффер. Мог бы быть возможный 2-й оффер. Почему возможный? Потому что много иностранных компаний хотят и готовы взять к себе на "борт"хороших специалистов, однако не все так просто. Ну например, украинские компании оформить в штат не резидента по украинскому законодательству не могут, если нет украинского гражданства/ВНЖ и разрешения на работу - это основные проблемные моменты, которые мешают. Да, можно зарегитрировать ИП и работать по договору подряда (гражданско-правовой договор). Но это уже другая история.
Еще, заметил, что частенько беларуские компании, почему-то, жлобятся на нормальную зп (ну камон!), при этом периодически планка с требованиями довольно высока. Еще раз, подчеркну, что не все так делают. Я не претендую на звание эксперта управления проектами, однако это мои наблюдения путем сравнения на протяжении длительного времени (я говорю о своей позиции PM) с требованиями и условиями, что предлагают те же украинские компании.
Относительно недавно я узнал о таком Jobs portal как Djinni.co. Хочу сказать, что динамика на этом сайте в разы лучше, чем даже в LinkedIn. Спустя 2-3 недели, мое резюме оказалось в Топ-10 по Минску. Оттуда, собственно, я и получил первый оффер меньше, чем за месяц (решение еще принимаю).
Итак, 20-23 интервью ~ 1 оффер. В принципе, неплохо. Зато за это время я смог лучше подготовиться, чтобы проходить интервью. Я даже составил серьезные вопросы, которые задаю интервьюерам. В итоге, получается полноценное интервью, в котором обе стороны узнают друг друга лучше.
Да, кстати, рекомендую вести борду (доску) по интервью в Trello. Это поможет структурировать ваши карточки-компании, которые вы заполняете с соответствующим фидбэком и сортируете в соответствии с нужным статусом по вашему флоу.
UPD: А сами вопросы я оформил в Гугл Док таблицу, вышло около 18. 1 вкладка = 1 компания. Это помогает проанализировать каждую компанию в отдельности и избавляет необходимость напрягаться вспоминать, о чем говорил рекрутер про свою компанию и вашу должность.
Следующий пост на этой неделе я опубликую по Требованиям и Иерархической структуре работ проекта (ИСР/WBS).
Всем Алоха!🖖🏻
Еще находясь в Дубае, я уже начал присматривать новое место работы. На данный момент пройдено около 22-23 интервью (именно взаимодействие от отклика/переписки с рекрутером до технического интервью). Итого - 1 оффер. Мог бы быть возможный 2-й оффер. Почему возможный? Потому что много иностранных компаний хотят и готовы взять к себе на "борт"хороших специалистов, однако не все так просто. Ну например, украинские компании оформить в штат не резидента по украинскому законодательству не могут, если нет украинского гражданства/ВНЖ и разрешения на работу - это основные проблемные моменты, которые мешают. Да, можно зарегитрировать ИП и работать по договору подряда (гражданско-правовой договор). Но это уже другая история.
Еще, заметил, что частенько беларуские компании, почему-то, жлобятся на нормальную зп (ну камон!), при этом периодически планка с требованиями довольно высока. Еще раз, подчеркну, что не все так делают. Я не претендую на звание эксперта управления проектами, однако это мои наблюдения путем сравнения на протяжении длительного времени (я говорю о своей позиции PM) с требованиями и условиями, что предлагают те же украинские компании.
Относительно недавно я узнал о таком Jobs portal как Djinni.co. Хочу сказать, что динамика на этом сайте в разы лучше, чем даже в LinkedIn. Спустя 2-3 недели, мое резюме оказалось в Топ-10 по Минску. Оттуда, собственно, я и получил первый оффер меньше, чем за месяц (решение еще принимаю).
Итак, 20-23 интервью ~ 1 оффер. В принципе, неплохо. Зато за это время я смог лучше подготовиться, чтобы проходить интервью. Я даже составил серьезные вопросы, которые задаю интервьюерам. В итоге, получается полноценное интервью, в котором обе стороны узнают друг друга лучше.
Да, кстати, рекомендую вести борду (доску) по интервью в Trello. Это поможет структурировать ваши карточки-компании, которые вы заполняете с соответствующим фидбэком и сортируете в соответствии с нужным статусом по вашему флоу.
UPD: А сами вопросы я оформил в Гугл Док таблицу, вышло около 18. 1 вкладка = 1 компания. Это помогает проанализировать каждую компанию в отдельности и избавляет необходимость напрягаться вспоминать, о чем говорил рекрутер про свою компанию и вашу должность.
Следующий пост на этой неделе я опубликую по Требованиям и Иерархической структуре работ проекта (ИСР/WBS).
#знания
СОДЕРЖАНИЕ ПРОЕКТА (часть 1).
Требования и иерархическая структура работ проекта.
ℹ️ Сперва определения 💬
* Описание содержания продукта (Product scope description) — это текстовый документ, который последовательно (сначала на высоком уровне, а затем более детально) уточняет характеристики продукта, услуги или результата, описанного в уставе проекта.
* Критерии приемки (Acceptance criteria) — четкий перечень условий, которые должны быть выполнены, чтобы результаты проекта могли быть приняты заказчиком. Это чек-лист, согласно которому заказчик будет принимать работу и проверять, насколько она соответствует его требованиям.
* Поставляемый результат (Deliverable) — любой уникальный и поддающийся проверке продукт, результат или способность оказывать услугу, которые необходимо произвести для завершения процесса, фазы или проекта. Т.е. какие артефакты проекта мы должны передать заказчику в итоге. Например, разработали мобильное приложение, то помимо приложения мы передаем исходный код, документацию, обученных сотрудников, подготовленных для поддержки и сопровождения приложения.
* Исключения из проекта (Project exclusions) — формулировка того, что именно находится вне содержания проекта. Т.е. описание того, что в проект не входит.
Касательно последнего — очень крутая штука! Например, проектный менеджер с заказчиком обсуждает устав проекта и работы по нему. Потом подключается еще один стейкхолдер, который предлагает “запилить” какую-то фичу, пусть это будет раздел аналитики на сайте, который мы разрабатываем. Нет проблем! Однако в первоначальной идее данной фичи не было предусмотрено. И в данном случае менеджеру лучше прописать в исключениях, что в рамках данного релиза этот функционал разрабатываться не будет. Это избавит от возможных недопониманий или даже конфликтов. Представьте себе, что спустя какой-то промежуток времени этот самый стейкхолдер приходит к руководителю и спрашивает, как продвигаются дела по его фиче. Тот вспоминают, что был такой разговор. Идут к вам спрашивать, а у вас ничего нет, кроме слов, мол, мы же перенесли это на другой релиз. Это возможный конфликт.
* Ограничения проекта (Project constraints) — то, в чем ограничивает нас заказчик. Например, в выборе субподрядчиков, технологии, методологии и т.п. Но ограничения по срокам и бюджету в этот пункт не вписываем (для них есть другое место).
*Допущения проекта (Project assumptions) — факторы, которые считаются верными без предоставления доказательств и демонстраций. Здесь описывается влияние этих факторов на проект. Это предположения, с которыми согласны вы и спонсор проекта. Без этих предположений дальнейшее планирование проекта невозможно.
Итак, все начинается с базового плана. Данный план нужен для сравнения текущего положения дел в проекте с изначальным планом. Т.к. в бизнесе могут происходить изменения, то и в плане тоже должны происходить изменения.
Существует три вида базового плана:
- По содержанию работ
- По стоимости
- По расписанию
Это же наш Треугольник PMI, где изменения в одном повлекут изменения в других.
Любые коррективы с базовым планом нужно согласовывать со спонсором проекта.
Базовый план по содержанию проекта состоит из требований к проекту, соответствующей иерархической структуры работ (ИСР) и ее словаря.
Сперва мы создаем высокоуровневые требования. Для этого мы готовим вопросы, которые впоследствии задаем заказчику. Допустим, мы сами это делаем (есть различные варианты сбора требований).
После того, когда все желания заказчика задокументированы, необходимо разделить их на требования и исключения.
Хорошие требования — это те, которые имеют четкий критерий завершенности (Definition of done/DoD).
Все требования должны быть задокументированы и согласованы со всеми стейкхолдерами.
СОДЕРЖАНИЕ ПРОЕКТА (часть 1).
Требования и иерархическая структура работ проекта.
ℹ️ Сперва определения 💬
* Описание содержания продукта (Product scope description) — это текстовый документ, который последовательно (сначала на высоком уровне, а затем более детально) уточняет характеристики продукта, услуги или результата, описанного в уставе проекта.
* Критерии приемки (Acceptance criteria) — четкий перечень условий, которые должны быть выполнены, чтобы результаты проекта могли быть приняты заказчиком. Это чек-лист, согласно которому заказчик будет принимать работу и проверять, насколько она соответствует его требованиям.
* Поставляемый результат (Deliverable) — любой уникальный и поддающийся проверке продукт, результат или способность оказывать услугу, которые необходимо произвести для завершения процесса, фазы или проекта. Т.е. какие артефакты проекта мы должны передать заказчику в итоге. Например, разработали мобильное приложение, то помимо приложения мы передаем исходный код, документацию, обученных сотрудников, подготовленных для поддержки и сопровождения приложения.
* Исключения из проекта (Project exclusions) — формулировка того, что именно находится вне содержания проекта. Т.е. описание того, что в проект не входит.
Касательно последнего — очень крутая штука! Например, проектный менеджер с заказчиком обсуждает устав проекта и работы по нему. Потом подключается еще один стейкхолдер, который предлагает “запилить” какую-то фичу, пусть это будет раздел аналитики на сайте, который мы разрабатываем. Нет проблем! Однако в первоначальной идее данной фичи не было предусмотрено. И в данном случае менеджеру лучше прописать в исключениях, что в рамках данного релиза этот функционал разрабатываться не будет. Это избавит от возможных недопониманий или даже конфликтов. Представьте себе, что спустя какой-то промежуток времени этот самый стейкхолдер приходит к руководителю и спрашивает, как продвигаются дела по его фиче. Тот вспоминают, что был такой разговор. Идут к вам спрашивать, а у вас ничего нет, кроме слов, мол, мы же перенесли это на другой релиз. Это возможный конфликт.
* Ограничения проекта (Project constraints) — то, в чем ограничивает нас заказчик. Например, в выборе субподрядчиков, технологии, методологии и т.п. Но ограничения по срокам и бюджету в этот пункт не вписываем (для них есть другое место).
*Допущения проекта (Project assumptions) — факторы, которые считаются верными без предоставления доказательств и демонстраций. Здесь описывается влияние этих факторов на проект. Это предположения, с которыми согласны вы и спонсор проекта. Без этих предположений дальнейшее планирование проекта невозможно.
Итак, все начинается с базового плана. Данный план нужен для сравнения текущего положения дел в проекте с изначальным планом. Т.к. в бизнесе могут происходить изменения, то и в плане тоже должны происходить изменения.
Существует три вида базового плана:
- По содержанию работ
- По стоимости
- По расписанию
Это же наш Треугольник PMI, где изменения в одном повлекут изменения в других.
Любые коррективы с базовым планом нужно согласовывать со спонсором проекта.
Базовый план по содержанию проекта состоит из требований к проекту, соответствующей иерархической структуры работ (ИСР) и ее словаря.
Сперва мы создаем высокоуровневые требования. Для этого мы готовим вопросы, которые впоследствии задаем заказчику. Допустим, мы сами это делаем (есть различные варианты сбора требований).
После того, когда все желания заказчика задокументированы, необходимо разделить их на требования и исключения.
Хорошие требования — это те, которые имеют четкий критерий завершенности (Definition of done/DoD).
Все требования должны быть задокументированы и согласованы со всеми стейкхолдерами.
#знания
СОДЕРЖАНИЕ ПРОЕКТА (часть 2).
Требования и иерархическая структура работ проекта.
Иерархическая структура работ (ИСР) или Work Breakdown Structure (WBS) — это список работ, которые необходимо выполнить, чтобы успешно завершить проект. ИСР формируется на базе требований к проекту и отражает только те работы, которые нужно выполнить в ходе проекта. Это основа планирования проекта.
Очевидный пример ИСР, это сборы для отпуска — мы пишем списком, что нам нужно собрать. Допустим, чемодан: перечисляем все вещи, которые нужно положить в него. Далее, рюкзак — все вещи, которые кладем туда. Документы: паспорта, билеты, ПЦР-тест, и т.д.
Важно декомпозировать все работы до того уровня, чтобы мы могли ими управлять. Все работы, что выше по списку — управляем, те, что ниже — должны знать, кто их будет выполнять, сколько нужно времени на это и как проверить, что работа готова. Нижний уровень называют пакетным уровнем. Делегирование + контроль исполнения.
Детализируя работы, менеджер должен знать, какой специалист будет нужен для конкретных/-ой задач/-и. Иначе он не сможет управлять работы проекта.
Обычно, хорошие примеры получаются на примере постройки дома.
Верхний уровень:
1. Подготовка фундамента
2. Строительство стен
3. Строительство крыши
4. Прокладка электрики
5. Подготовка сантехники
6. Отделочные работы и т.д.
Далее, детализация верхнеуровневых работ:
Фундамент
1.1 Подготовка котлована (вырыть, поставить блоки, армировать и т.д.)
1.2 Обрешетка фундамента
1.3 Заливка фундамента
1.4 Заливка площадки и т.д.
Когда делать ИСР? 🤔
Зависит от того, на каком этапе к нам попал проект. Если на этапе тендера, то можно построить высокоуровневую ИСР. Когда становится точно известно, что проект будет делать наша компания-исполнитель, то лучше сделать более детальную ИСР. Если проект уже стартовал, есть устав проекта, то ИСР должна быть полной и детализированной до уровня пакетов работ.
Подчеркну, что в ИСР неважно, в какой последовательности мы делаем работы, сколько они будут длиться и в какую сумму они обойдутся. Для этого у нас есть оценка и расписание.
Если требования вдруг меняются, при этом они все еще соответствуют целям бизнеса, то не стоит упираться и отказываться от изменений и ссылаться на ранее согласованные требования. Однако, обновить базовый план и ИСР будет нужно.
СОДЕРЖАНИЕ ПРОЕКТА (часть 2).
Требования и иерархическая структура работ проекта.
Иерархическая структура работ (ИСР) или Work Breakdown Structure (WBS) — это список работ, которые необходимо выполнить, чтобы успешно завершить проект. ИСР формируется на базе требований к проекту и отражает только те работы, которые нужно выполнить в ходе проекта. Это основа планирования проекта.
Очевидный пример ИСР, это сборы для отпуска — мы пишем списком, что нам нужно собрать. Допустим, чемодан: перечисляем все вещи, которые нужно положить в него. Далее, рюкзак — все вещи, которые кладем туда. Документы: паспорта, билеты, ПЦР-тест, и т.д.
Важно декомпозировать все работы до того уровня, чтобы мы могли ими управлять. Все работы, что выше по списку — управляем, те, что ниже — должны знать, кто их будет выполнять, сколько нужно времени на это и как проверить, что работа готова. Нижний уровень называют пакетным уровнем. Делегирование + контроль исполнения.
Детализируя работы, менеджер должен знать, какой специалист будет нужен для конкретных/-ой задач/-и. Иначе он не сможет управлять работы проекта.
Обычно, хорошие примеры получаются на примере постройки дома.
Верхний уровень:
1. Подготовка фундамента
2. Строительство стен
3. Строительство крыши
4. Прокладка электрики
5. Подготовка сантехники
6. Отделочные работы и т.д.
Далее, детализация верхнеуровневых работ:
Фундамент
1.1 Подготовка котлована (вырыть, поставить блоки, армировать и т.д.)
1.2 Обрешетка фундамента
1.3 Заливка фундамента
1.4 Заливка площадки и т.д.
Когда делать ИСР? 🤔
Зависит от того, на каком этапе к нам попал проект. Если на этапе тендера, то можно построить высокоуровневую ИСР. Когда становится точно известно, что проект будет делать наша компания-исполнитель, то лучше сделать более детальную ИСР. Если проект уже стартовал, есть устав проекта, то ИСР должна быть полной и детализированной до уровня пакетов работ.
Подчеркну, что в ИСР неважно, в какой последовательности мы делаем работы, сколько они будут длиться и в какую сумму они обойдутся. Для этого у нас есть оценка и расписание.
Если требования вдруг меняются, при этом они все еще соответствуют целям бизнеса, то не стоит упираться и отказываться от изменений и ссылаться на ранее согласованные требования. Однако, обновить базовый план и ИСР будет нужно.
#мнение
К сожалению, многие искренне уверены, что профессионализм сотрудника измеряется количеством времени, проведённым в профессии. Я считаю иначе: опыт, знания и умения. Чем их больше — тем профессиональнее специалист. Практический опыт, накопленный в реальных «боевых» проектах, бесценен и является конкурентным преимуществом. Конечно, от ошибок никто не застрахован, но, как говорят в народе, «за одного битого двух не битых дают».
К сожалению, многие искренне уверены, что профессионализм сотрудника измеряется количеством времени, проведённым в профессии. Я считаю иначе: опыт, знания и умения. Чем их больше — тем профессиональнее специалист. Практический опыт, накопленный в реальных «боевых» проектах, бесценен и является конкурентным преимуществом. Конечно, от ошибок никто не застрахован, но, как говорят в народе, «за одного битого двух не битых дают».
💯4
#юмор #горькаяправда
- Почему вас зовут Иван, а не Николай?
- В графе имя я ставлю вам минус.
https://youtu.be/QI-bXKC2mvU
- Почему вас зовут Иван, а не Николай?
- В графе имя я ставлю вам минус.
https://youtu.be/QI-bXKC2mvU
YouTube
Собеседование в IT
Собеседование в IT. Анимация о том, что иногда собеседования у программистов бывают очень странными.
😁1
#знания
Если команда не вкладывается в оценки 🤔
Эстимация — это бич всей разработки ПО. Давать точные оценки и попадать в них непросто. Негодуют клиенты, плачет команда, матерится менеджмент. ПМу тоже можно погрустить, но лучше что-нибудь предпринять. Чтобы исповедоваться реже попробуйте следующие благодетели:
1️⃣ Детализировать требования.
Чем четче сформулирована задача, тем точнее оценка.
2️⃣ Дробить фичи мельче.
Оптимально 1-4 дня.
3️⃣ Разбивать фичи на задачи (декомпозиция).
Выделяйте таски на бекенд, фронтенд, тестирование, и т.д. Максимум 1.5 дня на каждую. Если не выходит меньше — см. пункт 1.
4️⃣ Делать прототипы\инвестигейты на сложные фичи.
5️⃣ Проводить ретроспективы, обсуждать причины вылетов с командой.
6️⃣ Привлекать внешних спецов, если не хватает экспертизы.
7️⃣ Закладывать средний вылет в будущие оценки.
8️⃣ Трекать успеваемость (оценка vs. фактические затраты) по каждому члену команды. Доносить на митингах один-на-один.
9️⃣ Менять ребят, которые много и часто вылетают (>60% за 3-6 месяцев).
Вылет в 20-30% считается допустимой нормой, его стоит закладывать в начальную оценку.
Если команда не вкладывается в оценки 🤔
Эстимация — это бич всей разработки ПО. Давать точные оценки и попадать в них непросто. Негодуют клиенты, плачет команда, матерится менеджмент. ПМу тоже можно погрустить, но лучше что-нибудь предпринять. Чтобы исповедоваться реже попробуйте следующие благодетели:
1️⃣ Детализировать требования.
Чем четче сформулирована задача, тем точнее оценка.
2️⃣ Дробить фичи мельче.
Оптимально 1-4 дня.
3️⃣ Разбивать фичи на задачи (декомпозиция).
Выделяйте таски на бекенд, фронтенд, тестирование, и т.д. Максимум 1.5 дня на каждую. Если не выходит меньше — см. пункт 1.
4️⃣ Делать прототипы\инвестигейты на сложные фичи.
5️⃣ Проводить ретроспективы, обсуждать причины вылетов с командой.
6️⃣ Привлекать внешних спецов, если не хватает экспертизы.
7️⃣ Закладывать средний вылет в будущие оценки.
8️⃣ Трекать успеваемость (оценка vs. фактические затраты) по каждому члену команды. Доносить на митингах один-на-один.
9️⃣ Менять ребят, которые много и часто вылетают (>60% за 3-6 месяцев).
Вылет в 20-30% считается допустимой нормой, его стоит закладывать в начальную оценку.
#юмор
Поговорки к Agile активностям:
1. Демо: Сам себя не похвалишь – ходишь как оплеванный.
2. Стендап: В ногах правды нет.
3. Ретро: Кто старое помянет – тому глаз вон.
4. Планирование: Пути Господни неисповедимы.
Поговорки к Agile активностям:
1. Демо: Сам себя не похвалишь – ходишь как оплеванный.
2. Стендап: В ногах правды нет.
3. Ретро: Кто старое помянет – тому глаз вон.
4. Планирование: Пути Господни неисповедимы.
😁2
#знания
Коррекция расписания проекта 📈
1️⃣ Сломать расписание (Crushing) — это значит добавить больше ресурсов с целью сокращения общей длительности проекта.
Например, один человек соберет все сливы за 2 дня, то два человека соберут их за 1 день. Суть метода в том, чтобы привлечь в проект больше людей и выполнить его быстрее.
Ломая расписание, ПМ смотрит на операции, лежащие на критическом пути проекта, и анализирует, можно ли их выполнить быстрее, добавив людей в команду, если у него есть такая возможность.
2️⃣ Быстрый проход (Fast tracking) — сжать расписание проекта за счет накладывания операций, которые обычно выполняются последовательно, одной на другую.
Например, тестирование, обычно, выполняется после раразботки, но есть такая вероятность, что тестирование можно начать за неделю до завершения разработки, тем самым завершить проект быстрее на неделю.
Данный метод сокращает сроки, но часто приводит в дополнительным рискам и увеличению стоимости. Допустим, наши раработчики в последний момент внесли какие-то изменения в работу, то тестировщикам придется начинать работу с самого начала, а то, что они делали раньше станет пустой тратой времени и энергии.
3️⃣ Изменить подход — смотрим на проект и находим иной путь его реализации. Например, отказ от написания собственного решения и покупка нового. То есть, не разрабатывать систему управления программой лояльности, а купить готовую, проверенную временем, ставшей уже стандартом в этой области.
4️⃣ Произвести переоценку зависимостей — это, допустим, когда мы можем приступить к разработке только тогда, когда мы купим мощный сервер (зависимость "Финиш-Старт"). Или же арендовать сервер. Или временно делаем на старом, пока не приедет новый.
5️⃣ Пересмотреть жесткие ограничения (думаю, тут и так понятно).
❗️Обращаю внимание, что все методы сокращения расписания нужно применять строго к задачам, находящимся на критическом пути, так как сокращение задач вне критического пути может никак не повлиять на сроки сдачи проекта.
Коррекция расписания проекта 📈
1️⃣ Сломать расписание (Crushing) — это значит добавить больше ресурсов с целью сокращения общей длительности проекта.
Например, один человек соберет все сливы за 2 дня, то два человека соберут их за 1 день. Суть метода в том, чтобы привлечь в проект больше людей и выполнить его быстрее.
Ломая расписание, ПМ смотрит на операции, лежащие на критическом пути проекта, и анализирует, можно ли их выполнить быстрее, добавив людей в команду, если у него есть такая возможность.
2️⃣ Быстрый проход (Fast tracking) — сжать расписание проекта за счет накладывания операций, которые обычно выполняются последовательно, одной на другую.
Например, тестирование, обычно, выполняется после раразботки, но есть такая вероятность, что тестирование можно начать за неделю до завершения разработки, тем самым завершить проект быстрее на неделю.
Данный метод сокращает сроки, но часто приводит в дополнительным рискам и увеличению стоимости. Допустим, наши раработчики в последний момент внесли какие-то изменения в работу, то тестировщикам придется начинать работу с самого начала, а то, что они делали раньше станет пустой тратой времени и энергии.
3️⃣ Изменить подход — смотрим на проект и находим иной путь его реализации. Например, отказ от написания собственного решения и покупка нового. То есть, не разрабатывать систему управления программой лояльности, а купить готовую, проверенную временем, ставшей уже стандартом в этой области.
4️⃣ Произвести переоценку зависимостей — это, допустим, когда мы можем приступить к разработке только тогда, когда мы купим мощный сервер (зависимость "Финиш-Старт"). Или же арендовать сервер. Или временно делаем на старом, пока не приедет новый.
5️⃣ Пересмотреть жесткие ограничения (думаю, тут и так понятно).
❗️Обращаю внимание, что все методы сокращения расписания нужно применять строго к задачам, находящимся на критическом пути, так как сокращение задач вне критического пути может никак не повлиять на сроки сдачи проекта.
Алоха, друзья! 👋🏻
У меня родился вопрос: хотели бы вы разобраться, что такое критический путь, зачем он нужен в проекте, и, самое главное, как его правильно строить?
У меня родился вопрос: хотели бы вы разобраться, что такое критический путь, зачем он нужен в проекте, и, самое главное, как его правильно строить?
Anonymous Poll
81%
Да, было бы круто!
19%
Не интересно
❤1
Навигация по каналу
• #знания — методы, практики, подходы и приемы.
• #полезности — шаблоны, документы, схемы, диаграммы, сервисы, порталы — все, что помогает быть более продуктивным.
• #мойстатус — о моем текущем положении в профессиональной сфере.
• #горькаяправда — взлеты и падения в ИТ сфере, взаимодействии с людьми и т.п.
• #юмор — мемы, видео, ситуации из практики.
• #мнение — авторское мнение на те или иные вещи в работе.
• #моимысли — свои размышления в разных областях и(или) подходах управления.
• #инсайты — осознание каких-либо вещей в процессе работы, лайфхаки, которые пришли со временем.
• #новости — новости и анонсы из мира проектного менеджмента в ИТ, методологий и фреймворков, методик и подходов, а также интересных событий в ИТ-сфере.
• #партнерский_материал — интересные материалы, сервисы, каналы, ивенты и прочая полезная информация на партнерской основе.
• #кейсы — случаи из моего опыта или опыта других менеджеров.
• #знания — методы, практики, подходы и приемы.
• #полезности — шаблоны, документы, схемы, диаграммы, сервисы, порталы — все, что помогает быть более продуктивным.
• #мойстатус — о моем текущем положении в профессиональной сфере.
• #горькаяправда — взлеты и падения в ИТ сфере, взаимодействии с людьми и т.п.
• #юмор — мемы, видео, ситуации из практики.
• #мнение — авторское мнение на те или иные вещи в работе.
• #моимысли — свои размышления в разных областях и(или) подходах управления.
• #инсайты — осознание каких-либо вещей в процессе работы, лайфхаки, которые пришли со временем.
• #новости — новости и анонсы из мира проектного менеджмента в ИТ, методологий и фреймворков, методик и подходов, а также интересных событий в ИТ-сфере.
• #партнерский_материал — интересные материалы, сервисы, каналы, ивенты и прочая полезная информация на партнерской основе.
• #кейсы — случаи из моего опыта или опыта других менеджеров.
👍2🔥1
#реклама
Часто бывает так, что проект завершен в сроки и в нужном объеме, но клиенты все равно уходят из продукта. В этом случае стоит обратить внимание на проблемы в самом продукте.
Как? Проанализировать воронку, посмотреть на узкие места, протестировать гипотезы и спроектировать удобный для пользователей функционал. С этим поможет Product Games.
В своем канале Кристина Колузанова рассказывает про тестирование гипотез, фишки проектирования функционала, делится книгами и историями из жизни.
Хотите узнать больше про управление продуктами? Заходите в Product Games.
Часто бывает так, что проект завершен в сроки и в нужном объеме, но клиенты все равно уходят из продукта. В этом случае стоит обратить внимание на проблемы в самом продукте.
Как? Проанализировать воронку, посмотреть на узкие места, протестировать гипотезы и спроектировать удобный для пользователей функционал. С этим поможет Product Games.
В своем канале Кристина Колузанова рассказывает про тестирование гипотез, фишки проектирования функционала, делится книгами и историями из жизни.
Хотите узнать больше про управление продуктами? Заходите в Product Games.
Telegram
Product games с Кристиной Гусевой
Продакт-менеджер в New Yorker в Германии, ex-менеджер продукта в ВТБ ❤️
Рассказываю о карьере, делюсь, как строить продукты, которые пользователи полюбят
Сотрудничество - @KriGuseva
№ 4781101660
Рассказываю о карьере, делюсь, как строить продукты, которые пользователи полюбят
Сотрудничество - @KriGuseva
№ 4781101660
#мойстатус #горькаяправда
Алоха, друзья! 🖖🏻
Вижу, у нас прибавление на канале. Это приятно. Поэтому хочу еще раз напомнить новеньким, что тип канала — это журнал. Поэтому в нем я еще публикую заметки, помимо полезных постов.
Вот, например, буквально меньше недели назад я заболел короной…
Форма болезни проходит легко, слава Богу.
Да, это неприятная ситуация. Особенно, когда ты недавно устроился в новую компанию, запланирован созвон с иностранным клиентом, чтобы познакомиться, а ты внезапно уходишь в закат 😄
Благо я выбрал крутых ребят, которые по-человечески отнеслись к этой ситуации и всячески стараются поддерживать меня. Это чертовски приятно. Выбирайте правильную компанию, в которой будете работать.☝🏻
Как узнал о короне, сообщил об этом своему руководству и клиенту. Встречу перенесли на неопределенный срок, пока мне не станет лучше. Никаких проблем.
Во время больничного всегда есть, чем заняться. В моем случае я составил черновик с потенциальными вопросами по будущему проекту и людям на проекте, короткий план для мит & грита с клиентом. Если ты подготовлен — ты вооружен. Иногда, немного опасен 😄
Поэтому: «Самый лучший экспромт — подготовленный экспромт!».
Если набросаете сердечек, то я быстрее поправляюсь и опубликую обещанный пост 🙂.
Алоха, друзья! 🖖🏻
Вижу, у нас прибавление на канале. Это приятно. Поэтому хочу еще раз напомнить новеньким, что тип канала — это журнал. Поэтому в нем я еще публикую заметки, помимо полезных постов.
Вот, например, буквально меньше недели назад я заболел короной…
Форма болезни проходит легко, слава Богу.
Да, это неприятная ситуация. Особенно, когда ты недавно устроился в новую компанию, запланирован созвон с иностранным клиентом, чтобы познакомиться, а ты внезапно уходишь в закат 😄
Благо я выбрал крутых ребят, которые по-человечески отнеслись к этой ситуации и всячески стараются поддерживать меня. Это чертовски приятно. Выбирайте правильную компанию, в которой будете работать.☝🏻
Как узнал о короне, сообщил об этом своему руководству и клиенту. Встречу перенесли на неопределенный срок, пока мне не станет лучше. Никаких проблем.
Во время больничного всегда есть, чем заняться. В моем случае я составил черновик с потенциальными вопросами по будущему проекту и людям на проекте, короткий план для мит & грита с клиентом. Если ты подготовлен — ты вооружен. Иногда, немного опасен 😄
Поэтому: «Самый лучший экспромт — подготовленный экспромт!».
Если набросаете сердечек, то я быстрее поправляюсь и опубликую обещанный пост 🙂.
#полезности #знания
Что такое метод критического пути или сетевой график?
Критический путь (далее КП) — это все задачи, определяющие конечную дату запуска проекта. Если одна из задач нарушает график на один день, то весь проект будет задержан на этот срок. Часто возникают задачи, находящиеся вне плоскости критического пути. Это связано с отсутствием резервов времени в расписании. Резерв времени — срок, на который выполнение задачи может быть отложено без влияния на время запуска подзадач и дата завершения проекта не пострадает.
Чтобы определить КП, у нас должна быть известная последовательность работ. На базе диаграммы предшествования (Ганта) строится сетевой график. В сетевом графике узел выглядит так (изображение 1):
⁃ Ранний старт (Early Start) — самый ранний момент времени, в который может начаться запланированная операция.
⁃ Ранний финиш (Early Finish) — самый ранний момент времени, когда операция может быть завершена.
⁃ Поздний старт (Late Start) — самый поздний момент времени, в который может начаться запланированная операция, чтобы не задержать выполнение всего проекта. Здесь, если операция будет начинаться после этой даты, то весь проект будет задержан.
⁃ Поздний финиш (Late Finish) — самый поздний момент времени, когда операция может завершиться, не увеличив длительность всего проекта.
Например, возьмем диаграмму предшествования маленького проекта по созданию веб-сайта (изображение 2).
На ее базе мы рисуем сетевой график (изображение 3).
Обращаем внимание, на схеме появилась информация об узлах. Для каждой операции в центральной ячейке сверху цифрой прописана длительность ее исполнения. В первом блоке “Выработка требований” займет 3 дня, “Разработка дизайна” — 4 дня и т.д.
Устанавливаем дату начала проекта (= дата раннего старта первой операции) — ставим 0 у первых операций в ячейке раннего старта. Затем, добавляем длительность операции к дате начала, чтобы получить ранний финиш для первой операции. В примере это 0 + 3 = 3 дня.
Далее, в ячейку раннего старта следующей операции вписываем цифру раннего финиша предыдущей операции. Если предшествующих операций много, то в качестве раннего старта последующей операции выбираем самую позднюю дату раннего финиша. Например, “Согласование ТЗ” предшествуют сразу две операции: “Выработка требований” и “Разработка дизайна”. В дату раннего старта мы ставим 4 — самый поздний вариант (изображение 4).
Повторяем такие же действия слева-направо по всему графику, проходя по верхним ячейкам и заполняя даты раннего старта и раннего финиша для всех операций. Дата раннего финиша получится 25 (изображение 5). Это значит, что проект по созданию веб-сайта можно выполнить за 25 дней.
Теперь — обратный проход
В нижнюю правую ячейку позднего финиша операции “Демонстрация заказчику” пишем день завершения проекта из ячейки выше (25). Вычитаем длительность операции из позднего финиша, чтобы получить дату позднего старта операции — это 25 - 1 = 24. Вписываем 24 в левую нижнюю ячейку.
Далее, переносим дату (24) позднего старта из операции “Демонстрация заказчику” в ячейку позднего финиша следующей операции “Исправление ошибок”.
Если у предшествующей операции много других, то выбираем самую раннюю дату позднего старта предшествующей.
В итоге получается такой график (изображение 6).
Ну и осталось заполнить центральную ячейку снизу для каждой операции. Для этого нам нужно посчитать временной резерв — отнимаем от позднего старта ранний старт. В операции “Выработка требований” это 1 - 0 = 1. В операции “Согласование ТЗ” — это 4 - 4 = 0. И далее в таком же ключе. Во всей диаграмме в центральных ячейках, где получились нули — это и будет наш КП, на котором задержка этих операций приведет к задержке всего проекта. Серой заливкой показан КП (изображение 7). У всех отвальных операций есть резерв, т.к. они не лежат на КП и их задержка не повлияет на сроки сдачи всего проекта.
Так как несколько изображений в пост закрепить нельзя, поэтому ссылки на изображения смотрите в тексте.
Чуть позже сброшу задание, чтобы потренироваться с критическим путем.
Что такое метод критического пути или сетевой график?
Критический путь (далее КП) — это все задачи, определяющие конечную дату запуска проекта. Если одна из задач нарушает график на один день, то весь проект будет задержан на этот срок. Часто возникают задачи, находящиеся вне плоскости критического пути. Это связано с отсутствием резервов времени в расписании. Резерв времени — срок, на который выполнение задачи может быть отложено без влияния на время запуска подзадач и дата завершения проекта не пострадает.
Чтобы определить КП, у нас должна быть известная последовательность работ. На базе диаграммы предшествования (Ганта) строится сетевой график. В сетевом графике узел выглядит так (изображение 1):
⁃ Ранний старт (Early Start) — самый ранний момент времени, в который может начаться запланированная операция.
⁃ Ранний финиш (Early Finish) — самый ранний момент времени, когда операция может быть завершена.
⁃ Поздний старт (Late Start) — самый поздний момент времени, в который может начаться запланированная операция, чтобы не задержать выполнение всего проекта. Здесь, если операция будет начинаться после этой даты, то весь проект будет задержан.
⁃ Поздний финиш (Late Finish) — самый поздний момент времени, когда операция может завершиться, не увеличив длительность всего проекта.
Например, возьмем диаграмму предшествования маленького проекта по созданию веб-сайта (изображение 2).
На ее базе мы рисуем сетевой график (изображение 3).
Обращаем внимание, на схеме появилась информация об узлах. Для каждой операции в центральной ячейке сверху цифрой прописана длительность ее исполнения. В первом блоке “Выработка требований” займет 3 дня, “Разработка дизайна” — 4 дня и т.д.
Устанавливаем дату начала проекта (= дата раннего старта первой операции) — ставим 0 у первых операций в ячейке раннего старта. Затем, добавляем длительность операции к дате начала, чтобы получить ранний финиш для первой операции. В примере это 0 + 3 = 3 дня.
Далее, в ячейку раннего старта следующей операции вписываем цифру раннего финиша предыдущей операции. Если предшествующих операций много, то в качестве раннего старта последующей операции выбираем самую позднюю дату раннего финиша. Например, “Согласование ТЗ” предшествуют сразу две операции: “Выработка требований” и “Разработка дизайна”. В дату раннего старта мы ставим 4 — самый поздний вариант (изображение 4).
Повторяем такие же действия слева-направо по всему графику, проходя по верхним ячейкам и заполняя даты раннего старта и раннего финиша для всех операций. Дата раннего финиша получится 25 (изображение 5). Это значит, что проект по созданию веб-сайта можно выполнить за 25 дней.
Теперь — обратный проход
В нижнюю правую ячейку позднего финиша операции “Демонстрация заказчику” пишем день завершения проекта из ячейки выше (25). Вычитаем длительность операции из позднего финиша, чтобы получить дату позднего старта операции — это 25 - 1 = 24. Вписываем 24 в левую нижнюю ячейку.
Далее, переносим дату (24) позднего старта из операции “Демонстрация заказчику” в ячейку позднего финиша следующей операции “Исправление ошибок”.
Если у предшествующей операции много других, то выбираем самую раннюю дату позднего старта предшествующей.
В итоге получается такой график (изображение 6).
Ну и осталось заполнить центральную ячейку снизу для каждой операции. Для этого нам нужно посчитать временной резерв — отнимаем от позднего старта ранний старт. В операции “Выработка требований” это 1 - 0 = 1. В операции “Согласование ТЗ” — это 4 - 4 = 0. И далее в таком же ключе. Во всей диаграмме в центральных ячейках, где получились нули — это и будет наш КП, на котором задержка этих операций приведет к задержке всего проекта. Серой заливкой показан КП (изображение 7). У всех отвальных операций есть резерв, т.к. они не лежат на КП и их задержка не повлияет на сроки сдачи всего проекта.
Так как несколько изображений в пост закрепить нельзя, поэтому ссылки на изображения смотрите в тексте.
Чуть позже сброшу задание, чтобы потренироваться с критическим путем.
