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

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

Выдался у меня как-то на работе хороший год. Я сделал пару серьёзных проектов, за что получил существенную прибавку к окладу. Естественно, я захотел этот опыт повторить. Пришёл к директору и говорю – хочу +30%, готов стараться от всей души.

Тот почему-то обрадовался. Давай, говорит, всё-превсё автоматизируем в течение года, и будет тебе прибавка. Чтобы понять, кто такое «всё-превсё», мы собрали совещание всех отделов. Люди с радостью притащили хотелки, мы из сгруппировали в 13 проектов.

Увидев предстоящий объём работы, я, конечно, приуныл. А директор – наоборот. Когда все отделы ушли с совещания, он сказал: я тебе помогу. Ну, думаю, поможешь ты мне. Уже помог, спасибо.

Директор же сказал: я знаю, как тебе легко и быстро сделать все эти проекты. Ты, говорит, сам от себя офигеешь. Будем делать по-гибкому, в стиле эджайл.

Меня зовут Паша Мягков, я frontend tech lead в команде монетизации Учи.ру. Несколько месяцев назад рост команды и задач привел нас к тому, что привычные рабочие процессы перестали отвечать нашим потребностям. Болезнь роста затронула прозрачность разработки, планирование и workflow. В этой статье я расскажу, как в рамках одной быстро выросшей команды нам удалось наладить процессы.

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

Привет, менеджер!

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

Совсем немного введения

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

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

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

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

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

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

Но что такое пользовательская история?

Чтобы ответить на этот вопрос, давайте разделим это понятие на части:

Как много статей в интернете от матерых скрам-мастеров и их историй успехов. Прям читаешь и завидно становится.

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

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

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

У нас в компании 8 мобильных приложений и почти столько же мобильных команд. Конкретно наша работает с приложением для покупателей. Когда нас было немного, по 6-10 человек в iOS, Android и QA–командах, мы отлично справлялись с задачами. С ростом столкнулись с проблемой: чем больше у тимлида людей в подчинении, тем меньше он может уделить времени каждому, меньше времени имеет на погружение в задачи. В итоге качество управления команд начинало ухудшаться и с этим нужно было что-то делать 

Решение мы нашли в распределении команд по стримам. 

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

Дядя Боб

Привет! Меня зовут Света Друзь, я деврел в Beeline Казахстан. Отвечаю за коммуникацию и развитие комьюнити внутри компании, постоянно ищу новые интересные темы, подготавливаю спикеров и курирую проведение внутренних и внешних ивентов.

В апреле 2021 года мы провели большую онлайн-конференцию для разработчиков, IT-менеджеров и BigData-специалистов. В конференции приняли участие почти 2 000 человек, отметивших информативность и актуальность поднятых тем. 

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

Работа на коротких проектах похожа на курортный роман. Встретились, события закрутились, на пике эмоций помахали друг другу рукой. Другое дело, если проект длится годами. Тогда совместная проектная команда проживает запал на старте, а потом проходит через несколько кризисов как настоящая семейная пара. В таких историях менеджеру проекта не получится только отслеживать «сделали/не сделали». С особым рвением ему нужно следить за тем, чтобы мотивация команды не сдувалась, а еще поддерживать репутацию коллег в глазах клиента. Как? Делюсь своим опытом.

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

Если коротко, то в фарме нас ждёт примерно то же самое, что когда-то случилось с банками и ритейлом. Возможно, потому что на рынок эти самые банки уже пришли (СберЗдоровье и Магнит Фарма, например), и конкурировать придётся с их экосистемами. Фарма хочет собирать о вас максимум данных на своих платформах данных, развивать прямые контакты с вами (например, мобильные приложения пациентов, маркетплейсы и пр.) и строить из всех своих решений экосистему, чтобы от первого чиха до самой смерти вы были на подписке или постоянно покупали. Точнее, чтобы обмен был двусторонний: ваше состояние отслеживалось и передавалось в экспертную систему, которая позволяла бы вам жить дольше, пользуясь правильными препаратами и БАДами. 

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

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

Но я решил не отчаиваться и расширить круг своего любопытства до пределов СНГ.

Время — судья

Работая над обзором и обновлением книги «Мифический человеко-месяц», я поразился, как мало тезисы, заявленные в ней, были подвергнуты критике, доказаны или опровергнуты текущими исследованиями и опытом в инженерии ПО. Теперь для меня оказалось полезным каталогизировать эти тезисы в сырой форме, лишённой подтверждающих аргументов и данных. В надежде, что эти голые утверждения привлекут аргументы и факты для доказательства, опровержения, обновления или уточнения, я включил этот план в главу 18.

Кто празднику рад, тот накануне пьян

В споре рождается истина

В данной статье материал был собран летом 2020 года, отчасти информация устарела. Но хотелось бы поделиться собранным опытом. Автор текста: Анатолий Ерофеев.

Привет, Хабр! Меня зовут Екатерина Герт. Вот уже больше 10 лет я работаю системным аналитиком в проектах по заказной разработке ПО для компаний из разных отраслей и госсектора. Это всегда работа над большими проектами. 

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

Для меня это были непростые месяцы в моей карьере. Я хочу поделиться с вами своим опытом – как пережить такие ситуации, не перегореть и завершить работу в срок. Моя история может быть полезна тем, кто переживает аврал на работе и ищет способы выйти из него без потерь.

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

Поехали! 

Тимлидами редко рождаются, чаще — становятся. Самый частый пример, который я видел — тимлидом назначают самого ответственного разработчика из команды. Наделить ответственного человека еще большей ответственностью — сильное и эффективное решение, правда же? 

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

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

Требования меняются и расширяются в ходе любого проекта. Это естественный аспект разработки программного обеспечения. Менеджер проекта должен предвидеть и планировать это, например, путем включения буферов в планы на случай непредвиденных обстоятельств при взятии на себя обязательств. Расползание рамок (от англ. "scope creep", также известное как расползание возможностей и расползание требований), однако, относится к неконтролируемому расширению возможностей, которые команда пытается запихнуть в уже переполненный проект. Все это не помещается.

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

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

Оптимизация бизнес-процессов играет важнейшую роль в повышении операционной эффективности компании. В SberPM обучение с подкреплением используется для реконструкции процесса в соответствии с заданными критериями:

·         Отсутствие зацикленности.

·         Минимальное время выполнения этапов.

·         Минимальное число этапов.

·         Успешное завершение процесса.

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

Я думаю, главная причина непонимания — в том как мы, инженеры и разработчики, пытаемся объяснять бизнесу, почему важно избавляться от техдолга. Мы транслируем наше видение из нашего технического мира, забывая, что у бизнеса другие критерии оценки важности проблем. Мой доклад, с которым я выступил на DevOpsConf 2021, как раз о том, как устранить это непонимание и «продать» бизнесу технический долг.