#юмор #горькаяправда
- Почему вас зовут Иван, а не Николай?
- В графе имя я ставлю вам минус.
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). У всех отвальных операций есть резерв, т.к. они не лежат на КП и их задержка не повлияет на сроки сдачи всего проекта.
Так как несколько изображений в пост закрепить нельзя, поэтому ссылки на изображения смотрите в тексте.
Чуть позже сброшу задание, чтобы потренироваться с критическим путем.
#знания #полезности
Итак, первая задачка по нахождению критического пути.
Условия просты:
Определить критический путь в этих работах.
Первая колонка — наименование работ (подсказка: последовательность — в алфавитном порядке)
Вторая колонка — длительность работ в днях
Третья колонка — взаимосвязанные работы
Start — от этой работы все начинается (у нас два старта).
Смотрим на предыдущий пост и пробуем изобразить на бумаге (рекомендую).
Комменты остаются открытыми для обсуждения.
Итак, первая задачка по нахождению критического пути.
Условия просты:
Определить критический путь в этих работах.
Первая колонка — наименование работ (подсказка: последовательность — в алфавитном порядке)
Вторая колонка — длительность работ в днях
Третья колонка — взаимосвязанные работы
Start — от этой работы все начинается (у нас два старта).
Смотрим на предыдущий пост и пробуем изобразить на бумаге (рекомендую).
Комменты остаются открытыми для обсуждения.
👍3
#знания #полезности
Даю подсказку следующего шага — схема, изображенная справа на рисунке.
Вашим следующим этапом будет построить схему с предшествующими работами, указав зависимости: Ранний Старт-Ранний Финиш, Поздний Старт-Поздний Финиш.
Даю подсказку следующего шага — схема, изображенная справа на рисунке.
Вашим следующим этапом будет построить схему с предшествующими работами, указав зависимости: Ранний Старт-Ранний Финиш, Поздний Старт-Поздний Финиш.
👍2
#знания #полезности
Заключительная часть с задачей.
Сверяйтесь с шагами в предыдущих постах, чтобы детально разорабраться с этой темой.
Итого, критический путь у нас будет — E, B, D.
Ориентируемся на нижние нули в центре блоков.
Надеюсь, снова объяснять, почему так не нужно.
Добавлю только, что построение КП в наших реалиях не является супер-обязательным, но это желательно. Есть факторы, говорящие о нецелесообразности построения КП с точки зрения трудозатрат.
Например, мой случай на одном из проектов, где моя команда интегрировалась в уже существующий проект к другой внешней команде по разработке, в котором мы используем Agile-подходы, а условия и сроки довольно гибкие. Да, это не означает, что КП нужно игнорировать. Я просто не увидел необходимости тратить время на него. В нашем случае видением развития продукта и сроками управляет непосредственно PO, а не заказчик. Заказчику важен результат. И то, что мы сами напланировали, мы должны выполнить.
Скоро расскажу немного о своем статусе в работе.
Заключительная часть с задачей.
Сверяйтесь с шагами в предыдущих постах, чтобы детально разорабраться с этой темой.
Итого, критический путь у нас будет — E, B, D.
Ориентируемся на нижние нули в центре блоков.
Надеюсь, снова объяснять, почему так не нужно.
Добавлю только, что построение КП в наших реалиях не является супер-обязательным, но это желательно. Есть факторы, говорящие о нецелесообразности построения КП с точки зрения трудозатрат.
Например, мой случай на одном из проектов, где моя команда интегрировалась в уже существующий проект к другой внешней команде по разработке, в котором мы используем Agile-подходы, а условия и сроки довольно гибкие. Да, это не означает, что КП нужно игнорировать. Я просто не увидел необходимости тратить время на него. В нашем случае видением развития продукта и сроками управляет непосредственно PO, а не заказчик. Заказчику важен результат. И то, что мы сами напланировали, мы должны выполнить.
Скоро расскажу немного о своем статусе в работе.
#мойстатус 🎅🏻
Компания, в которой я сейчас работаю относится к домену финтех. Мы разрабатываем, преимущественно, мобильные приложения, иногда — веб. Компания небольшая, около 80+ чел.
Проект у меня пока один — разработка мобильного приложения для трейдинга для одного бренда (брокера). Наша минская команда ваяет продукт совместно с украинскими ребятами. Работаем по фреймворку SAFe (масштабируемый Scrum. Глоссарий терминов SAFe). Если коротко, то это большая команда, состоящая из нескольких подкоманд (= вагон, а все вагоны = поезд), каждая из которых занимается своим направлением (веб, мобилки, дизайн, etc.). В фреймворке есть несколько уровней. На уровне Team and Technical Agility — это Scrum-Master (в своей подкоманде эту роль выполняю я + менеджерю минскую команду), и Product Owner. На уровне DevOps and Release on Demand — это RTE (Release Train Engineer), System Architect/Engineer, Product Manager (их несколько), а также Business owners. Далее — уровень бизнеса и системы — это Solution Architect/Engineer, STE (Solution Train Enginner), Solution Manager, и последний уровень — Lean Portfolio Managemnet — зона бизнеса, транслируемая уже на весь Enterprise. На ней останавливаться не будем.
Почти все то же, что в Скрам, только тут больше людей, есть доп. церемонии для лидов и ответственных лиц каждой из подкоманд, новые роли и уровни компетенций. С некоторыми ролями я даже не пересекаюсь. В целом, все выглядит гармонично. Такие фреймворки, обычно, хорошо подходят для больших и/или сложных Enterprise-проектов.
Работаем мы с сервисом Microsoft Azure Devops, который является как таск-трекером, аналитикой прогресса работы, так и код-репозиторием и сервером.
Из ключевых особенностей жизни проекта:
Спринты — двухнедельные.
Ивенты: daily-meetings, PBR (Product Backlog Refinement aka Grooming), Planning, Demo (Sprint Review как такового нет), Retrospectives.
На PBR мы оцениваем в относительных единицах (Story Points) юзер-стори из подготовленного Product Owner’ом Бэклогом согласно практике Planning Poker. В оценке участвуют разработчики и QA.
На Planning, оцененные стори, мы закидываем в Спринт Бэклог и распределяем их на участников команды.
Также, следим за Remaining time в каждом тикете стори и задачи, чтобы был виден наглядный прогресс работы (эта функция имеется в Azure Devops).
А еще мне прям нравится, как проходит демо продукта:
Каждая подкоманда готовит короткую демо-презентацию с описанием Sprint Goal, что сделали/не сделали + наглядная демонстрация с шэрингом экрана. Созвон проходит в MS Teams, где собираются все участники проекта, а это около 140+ человек. На каждом стендапе спикера заказчики и стейкхолдеры могут задать свои вопросы. На все уходит около часа. Из-за подготовленности спикеров, демо выглядит четким. Пока что я не встречал еще такого уровня подготовки демо.
В общем, трейдить, конечно, это одно, но вот разрабатывать аппку для трейдинга — это другое. Если ты трейдишь, то эти знания не особо помогут в разработке приложения, т.к. нужно еще понимать, как происходит калькуляция ордеров, торговых приказов и т.п., какие есть особенности инструментов (ассетов), чем они отличаются, что такое хеджинг и неттинг, в чем их особенности и т.д. Сразу голова взрывается, но потом становится легче 🙂
Компания, в которой я сейчас работаю относится к домену финтех. Мы разрабатываем, преимущественно, мобильные приложения, иногда — веб. Компания небольшая, около 80+ чел.
Проект у меня пока один — разработка мобильного приложения для трейдинга для одного бренда (брокера). Наша минская команда ваяет продукт совместно с украинскими ребятами. Работаем по фреймворку SAFe (масштабируемый Scrum. Глоссарий терминов SAFe). Если коротко, то это большая команда, состоящая из нескольких подкоманд (= вагон, а все вагоны = поезд), каждая из которых занимается своим направлением (веб, мобилки, дизайн, etc.). В фреймворке есть несколько уровней. На уровне Team and Technical Agility — это Scrum-Master (в своей подкоманде эту роль выполняю я + менеджерю минскую команду), и Product Owner. На уровне DevOps and Release on Demand — это RTE (Release Train Engineer), System Architect/Engineer, Product Manager (их несколько), а также Business owners. Далее — уровень бизнеса и системы — это Solution Architect/Engineer, STE (Solution Train Enginner), Solution Manager, и последний уровень — Lean Portfolio Managemnet — зона бизнеса, транслируемая уже на весь Enterprise. На ней останавливаться не будем.
Почти все то же, что в Скрам, только тут больше людей, есть доп. церемонии для лидов и ответственных лиц каждой из подкоманд, новые роли и уровни компетенций. С некоторыми ролями я даже не пересекаюсь. В целом, все выглядит гармонично. Такие фреймворки, обычно, хорошо подходят для больших и/или сложных Enterprise-проектов.
Работаем мы с сервисом Microsoft Azure Devops, который является как таск-трекером, аналитикой прогресса работы, так и код-репозиторием и сервером.
Из ключевых особенностей жизни проекта:
Спринты — двухнедельные.
Ивенты: daily-meetings, PBR (Product Backlog Refinement aka Grooming), Planning, Demo (Sprint Review как такового нет), Retrospectives.
На PBR мы оцениваем в относительных единицах (Story Points) юзер-стори из подготовленного Product Owner’ом Бэклогом согласно практике Planning Poker. В оценке участвуют разработчики и QA.
На Planning, оцененные стори, мы закидываем в Спринт Бэклог и распределяем их на участников команды.
Также, следим за Remaining time в каждом тикете стори и задачи, чтобы был виден наглядный прогресс работы (эта функция имеется в Azure Devops).
А еще мне прям нравится, как проходит демо продукта:
Каждая подкоманда готовит короткую демо-презентацию с описанием Sprint Goal, что сделали/не сделали + наглядная демонстрация с шэрингом экрана. Созвон проходит в MS Teams, где собираются все участники проекта, а это около 140+ человек. На каждом стендапе спикера заказчики и стейкхолдеры могут задать свои вопросы. На все уходит около часа. Из-за подготовленности спикеров, демо выглядит четким. Пока что я не встречал еще такого уровня подготовки демо.
В общем, трейдить, конечно, это одно, но вот разрабатывать аппку для трейдинга — это другое. Если ты трейдишь, то эти знания не особо помогут в разработке приложения, т.к. нужно еще понимать, как происходит калькуляция ордеров, торговых приказов и т.п., какие есть особенности инструментов (ассетов), чем они отличаются, что такое хеджинг и неттинг, в чем их особенности и т.д. Сразу голова взрывается, но потом становится легче 🙂
Отличная новость! 🥳
Теперь реакции можно сразу ставить на сообщения.
Предлагаю затестить эту новую фичу от Телеграм на канале. Можно на этом сообщении сразу и прочекать. 🙂
Теперь реакции можно сразу ставить на сообщения.
Предлагаю затестить эту новую фичу от Телеграм на канале. Можно на этом сообщении сразу и прочекать. 🙂
🔥4🎉1🐳1
Выходим из информационного отпуска 👊🏻
Если присмотреться, то публикаций не было около 1,5 месяцев. На то были свои причины. В первую очередь мне нужен был информационный отдых, т.к. скопилась некая усталость от инф. потока. Все-таки, непросто быть в ресурсе 24/7, 7 дней в неделю и 365 дней в году. Поэтому я воздерживался постить что-то незначительное или вообще ни о чем. Не люблю лить воду. Иногда где-то и проскакивает, но все мы не без греха. 😄
Поэтому я расскажу скоро про этапы жизненного цикла проекта. А именно — погрузимся в каждый этап отдельно — что входит в каждый этап, обязательные/необязательные пункты, какие-то особенности и т.д. Тема очень объемная, но интересная.
А подкиньте 🔥 кому не лень, кто еще здесь 😃
Если присмотреться, то публикаций не было около 1,5 месяцев. На то были свои причины. В первую очередь мне нужен был информационный отдых, т.к. скопилась некая усталость от инф. потока. Все-таки, непросто быть в ресурсе 24/7, 7 дней в неделю и 365 дней в году. Поэтому я воздерживался постить что-то незначительное или вообще ни о чем. Не люблю лить воду. Иногда где-то и проскакивает, но все мы не без греха. 😄
Поэтому я расскажу скоро про этапы жизненного цикла проекта. А именно — погрузимся в каждый этап отдельно — что входит в каждый этап, обязательные/необязательные пункты, какие-то особенности и т.д. Тема очень объемная, но интересная.
А подкиньте 🔥 кому не лень, кто еще здесь 😃
🔥8
#горькаяправда #статус
Кто-бы мог подумать, что мы окажемся в такой ситуации. 4-й день я пребываю в шоке и до сих пор все в голове не укладывается от происходящего. Словно это происходит не наяву.
Я долго думал писать что-то или нет, но, все-таки, решился, ведь это наша жизнь. И в данный момент это очень серьезное событие.
У нас в Беларуси тоже непростая ситуация, которая может обернуться в ближайшее время в первую очередь для наших мужчин отправкой в Украину.
Что касается проекта, то украинским ребятам, с которыми мы работаем, с 24-го февраля было точно не до работы, и минская команда старалась работать самостоятельно, несмотря на случившееся. Мы старались сохранять холодный рассудок и не сеять панику внутри команды. Однако, на второй день со своей стороны, видя ухудшение положения, мы поддержали украинских коллег словесно в нашем рабочем чатике, т.к. было видно, что им страшно.
Также, в виду возможного осложнения в моей стране и касательно мобилизации гражданских, моя компания прорабатывает план по защите своих сотрудников, вплоть до релокации.
Нужно быть готовым в любой момент.
Надеюсь, следующий пост будет и он будет в мирное время и по теме.
Берегите себя и близких. 🙏🏻♥️
Кто-бы мог подумать, что мы окажемся в такой ситуации. 4-й день я пребываю в шоке и до сих пор все в голове не укладывается от происходящего. Словно это происходит не наяву.
Я долго думал писать что-то или нет, но, все-таки, решился, ведь это наша жизнь. И в данный момент это очень серьезное событие.
У нас в Беларуси тоже непростая ситуация, которая может обернуться в ближайшее время в первую очередь для наших мужчин отправкой в Украину.
Что касается проекта, то украинским ребятам, с которыми мы работаем, с 24-го февраля было точно не до работы, и минская команда старалась работать самостоятельно, несмотря на случившееся. Мы старались сохранять холодный рассудок и не сеять панику внутри команды. Однако, на второй день со своей стороны, видя ухудшение положения, мы поддержали украинских коллег словесно в нашем рабочем чатике, т.к. было видно, что им страшно.
Также, в виду возможного осложнения в моей стране и касательно мобилизации гражданских, моя компания прорабатывает план по защите своих сотрудников, вплоть до релокации.
Нужно быть готовым в любой момент.
Надеюсь, следующий пост будет и он будет в мирное время и по теме.
Берегите себя и близких. 🙏🏻♥️
❤3
#полезности #реклама
В непростое время каждый старается чем-то помочь. Имея голову на плечах и включая критическое мышление, можно сделать многое разными способами и принести не меньше пользы.
Один из таких способов сейчас — это моя группа по поиску работы в ИТ — JobsearchIT. 🔍
Сейчас мы стараемся фокусироваться особенно на тех, кто потерял работу по понятным нам причинам. Поэтому, если вы или ваши знакомые потеряли/ищут работу, запрыгивайте в группу.
Место всем найдется! 🙌🏻
В непростое время каждый старается чем-то помочь. Имея голову на плечах и включая критическое мышление, можно сделать многое разными способами и принести не меньше пользы.
Один из таких способов сейчас — это моя группа по поиску работы в ИТ — JobsearchIT. 🔍
Сейчас мы стараемся фокусироваться особенно на тех, кто потерял работу по понятным нам причинам. Поэтому, если вы или ваши знакомые потеряли/ищут работу, запрыгивайте в группу.
Место всем найдется! 🙌🏻
👏2
#мойстатус #горькаяправда #полезности
Проект закрыт. В ожидании. Параллельно присматриваю что-то новое. Сейчас, преимущественно рассматриваю с релокацией в другую страну.
Вижу, в Линкедин, много людей потеряли работу, так же закрылись проекты. Грустная картина… Тем не менее спрос на рынке не пропал и даже подрос. Сейчас достаточно сеньористых ребят оказалось за бортом, а для компаний это хорошая возможность заполучить хорошего спеца. Спрос на высококвалифицированных спецов всегда был высок, а сейчас тем более.
Я уже, как-то говорил, что у меня есть Телеграм-группа по поиску работы в регионах Беларуси, России, Украине и Европе. Так вот я принял решение сделать фокус на то, чтобы сосредоточить соискателей и рекрутеров в одной группе. Из статистики скажу, что правильно настроенные процессы и администрирование дает плоды в виде откликов и даже офферов из группы. А в такой период это осбенно важно.
Буквально за пару недель с 2,5к подписчиков, группа увеличилась до 3,5к (на момент написания поста). Вся аудитория — целевая. Никаких ботов и нерелевантных сообщений, что очень ценно. Сейчас для меня важно, чтобы люди находили то, что искали, помочь им советом в оформлении постов, резюме, поделиться полезными материалами или просто советом.
Проект закрыт. В ожидании. Параллельно присматриваю что-то новое. Сейчас, преимущественно рассматриваю с релокацией в другую страну.
Вижу, в Линкедин, много людей потеряли работу, так же закрылись проекты. Грустная картина… Тем не менее спрос на рынке не пропал и даже подрос. Сейчас достаточно сеньористых ребят оказалось за бортом, а для компаний это хорошая возможность заполучить хорошего спеца. Спрос на высококвалифицированных спецов всегда был высок, а сейчас тем более.
Я уже, как-то говорил, что у меня есть Телеграм-группа по поиску работы в регионах Беларуси, России, Украине и Европе. Так вот я принял решение сделать фокус на то, чтобы сосредоточить соискателей и рекрутеров в одной группе. Из статистики скажу, что правильно настроенные процессы и администрирование дает плоды в виде откликов и даже офферов из группы. А в такой период это осбенно важно.
Буквально за пару недель с 2,5к подписчиков, группа увеличилась до 3,5к (на момент написания поста). Вся аудитория — целевая. Никаких ботов и нерелевантных сообщений, что очень ценно. Сейчас для меня важно, чтобы люди находили то, что искали, помочь им советом в оформлении постов, резюме, поделиться полезными материалами или просто советом.
👍4🔥1
Привет 👋🏻
Сидеть ровно нельзя 🚫
Нужно двигаться дальше, обучаться чему-то новому и совершенствовать текущие навыки. Жизнь не останавливается.🕊
Поэтому буду продолжать постить образовательный и жизненный контент дальше. Нас ждет объемная тема о ЖЦП (см. последний абзац).
P.S. Не забываем, что формат канала — мой дневник 📔
Сидеть ровно нельзя 🚫
Нужно двигаться дальше, обучаться чему-то новому и совершенствовать текущие навыки. Жизнь не останавливается.🕊
Поэтому буду продолжать постить образовательный и жизненный контент дальше. Нас ждет объемная тема о ЖЦП (см. последний абзац).
P.S. Не забываем, что формат канала — мой дневник 📔
👍5