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

Привет. Меня зовут Артур.

Я руковожу проектным офисом в Сказбуке.

Мы разрабатываем мобильное приложение, которое в игровой форме развивает мышление и таланты ребенка.

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

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

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

Как все начиналось? 

До перестроения, основной проект развивался в сторону увеличения объема контента. Новые игры старались выпускать в среднем каждые 2-3 недели. Над каждой игрой работала отдельная группа сотрудников, которые отвечали за реализацию –  «юнит-команда». Они в короткие сроки проходили весь цикл разработки от идеи и разработки концепта  до финального тестирования и публикации. 

Расскажу откровенно наш опыт развития SaaS-сервиса в России с нуля до стабильной выручки в ~600 тысяч рублей в месяц без венчурных инвестиций, ChatGPT и платной рекламы (уже скучно, да? :)). Кому-то выручка может показаться скромной, но мы радуемся как дети. Сразу говорю — быстро не будет, особенно если вы работаете «на своих», но зато в статье будет много графиков.

Меня зовут Максим Кульгин и мы развиваем сервис clickfraud.ru — защита от скликивания рекламы Яндекс. Директ. В марте 2023 г. мы получили рекордную для нас выручку за всю историю сервиса (мы еще молодой стартап) . Поделюсь нашим опытом наиболее интересных и значимых моментов в развитии. Статью сделал в виде пунктов, так получается более системно выделить основные моменты. Сразу скажу — нам нужно еще очень много улучшать по всем «фронтам» — по алгоритмам защиты, ux/ui сайта, личной кабинет, отчетам и т. п. Получается бесконечный процесс улучшения, которому не видно конца и края.

Т. к. развиваемся на свои средства, без венчурных инвестиций, то получается все очень не быстро, мягко говоря. Доменное имя мы зарегистрировали в конце 2019 года, по сути активно развиваем сервис 2 года. В октябре 2022 года получили грант от ФСИ (4 млн. руб., можно тратить только на ФОТ) , стали резидентом Сколково и это нас ускорило (смогли усилить команду разработчиков, математиков — обнаружение ботов, которые скликивают рекламу, исключительно математическая задача, а если быть точным — ИИ для обнаружения аномалий в движениях мышки) . Я уже писал наш детальный опыт получения гранта и то, как мы стали резидентом Сколково с разбором заявки.

SCRUM в России, как и на территории всего бывшего СССР, стал самой популярной методологией разработки ПО не только среди любых «гибких» вариаций и даже среди всех итерационных производственных парадигм. И, действительно, с 2013 года научные исследования консультантов SSC последовательно показывают:

1. SCRUM наращивал свою востребованность и с 2017 года явно доминирует среди «гибких» методологий: часть из них (вроде XP) не вызывают энтузиазма в крупных организациях, часть из них (например, KANBAN) вообще не внедрены нигде, кроме как посреди субъективных ощущений отдельных генеральных директоров отдельных web‑студий;

2. SCRUM к 2020 году стал основной методологией разработки для лучших российских софтверных вендоров, как для обеспечения критериев качества продукта, так и с точки зрения оптимизации продуктивности и загрузки команд.

Безусловно остаются целые области российской IT‑отрасли, в которых инженеры ничего не знают про SCRUM, но будем честны: они ничего не знают и в целом о программной инженерии 20-х годов нашего века, а их программное обеспечение могло быть создано 20 и даже 30 лет назад: ведь это те же самые задачи автоматизации для самолетов, ракет и станков, которые и сами превосходно «помнят» 20-й век. Коммерческая разработка выбрала SCRUM‑методологию и последовательно преодолевает разнообразные сложности этой парадигмы. Одна из регулярно возникающих задач — это необходимость снижать себестоимость команды в «тяжелые» для бизнес‑заказчиков времена.

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

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

X‑фактор — это в реальности наличествующий, действующий и влияющий ключевым образом фактор, но по каким‑то причинам не уловимый и не замечаемый, не учитываемый и не принимаемый во внимание и в расчёт, из‑за чего на нём не делается акцент.

Исходя из названия статьи, «задача» — это и есть такой X‑фактор в менеджменте (управлении).

Но парадокс заключается и в том, что «задача» не просто X‑фактор, а ещё и «квинтэссенция» менеджмента.

Встаёт вопрос: почему задача — это X‑фактор управления и его квинтэссенция?

То, что задача — X‑фактор, я обнаружил, когда писал статью «Что такое задача?«^[3] и искал определение задачи. И, как ни странно, не находил. Из‑за чего писал: „Сначала я хотел взять уже имеющееся понятие „задачи“. Думал, раз оно не сходит с уст, и все его применяют, значит, оно должно быть. Каково же было моё удивление, когда я не смог найти в Интернет однозначного определения задачи. Такого вот, чтобы было чётко дано: „задача — это то‑то и то‑то“. Чтобы можно было по этому определению её идентифицировать и отделить от других сущностей. Не нашёл“.

В указанной статье, конечно же, я разобрал эту проблему, можете почитать. Но «на ус намотал». Отметил — неспроста это.

Затем я на это обратил внимание в том же разделе в статье «Чем задача отличается от цели?«. Там я задавался вопросами: „Все же руководители и не только руководители постоянно применяют фразы: „поставил задачу“, „наша задача“, „я озадачил подчинённого“, „выполнение задач показало“, „лишить премии за невыполнение задачи“ и т. д. Не уж‑то они не осознают, что главное — это задача. Постоянно этим оперируют и не осознают?“.

Под грустное рычание,
Под бодрое мычание,
Под дружеское ржание
Рождается на свет
Большой СКЕЛЕТ для маленькой,
Для маленькой такой компании,
Для скромной такой компании
Огромный такой СКЕЛЕТ!

В настоящее время в интернете много эфирного времени посвящено обсуждению различных достоинств масштабирования Agile и ведущих подходов в этой области: Scaled Agile Framework (SAFe http://www.scaledagileframework.com) и Large Scale Scrum (LeSS http://www.craiglarman.com/Large-Scale_Scrum ).

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

На бумаге …

SAFe основан на работе Дина Леффингвелла (Dean Leffingwell), и был формализован в виде фреймворка в 2011 году. Я работал с Дином в 2008 во время руководства командой консультантов в одной крупной многонациональной компании мобильной связи, помогая им определить и внедрить ранний подход к планированию Agile Release Train (ART)  –  то, что теперь эволюционировало в SAFe.

Михаил Михайлец, руководитель группы аналитиков направления облачных решений Лиги Цифровой Экономики, рассказал, как его команда попробовала быстро подготовить задачи по классическому ТЗ (ГОСТ 19) в Jira при работе с государственным заказчиком и что из этого получилось.

Пожалуй, большинству известно, что ГОСТ предусматривает водопадную модель разработки ПО. До недавнего времени она была зафиксирована в постановлении Правительства Российской Федерации от 6 июля 2015 г. № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации».

Несмотря на обнадеживающее движение в сторону итеративной разработки со стороны правительства, стандарты пока обновляться не спешат. Годы выпуска действующих ГОСТов, которые идут после тире в их номерах, тонко намекают, что гибкие подходы в разработке не учитывались при их создании.

В теории можно породить жизнеспособного «кентавра» — если в течение спринтов проходить указанные стадии проекта раз за разом в ходе разработки каждой функции приложения.

Привет, это Максим Павлов, управляющий партнер KTS. 

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

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

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

Если в Вашей IT‑компании принят проектный подход в производстве ПО или IT‑сервисов, а тем более, есть формализованный проектный офис, то, почти наверняка, есть пара параметров его деятельности, которые нуждаются в улучшении. И если в вашей IT‑компании работает более 40 человек, то эти параметры — это прозрачность и предсказуемость проектной деятельности. Мы все знаем, как сложно продать заказчику высокорискованный IT‑проект с технологиями «на гребне волны прогресса», но еще сложнее его потом сделать (в рамках бюджета, функциональных рамок, сроков и с превосходным уровнем качества). Если в Вашем проектном управлении не хватает организованности, упорядоченности и прозрачности, то о предсказуемости проектной деятельности не стоит даже мечтать. IT‑проект — это не скатерть‑самобранка, скорее всего ваш проданный проект ждет провал, а Вы о нем узнаете лишь ближе к его середине. Более того, к этому моменту вся команда разработки уже изрядно устанет, коммуникации с заказчиками будут требовать серьезного улучшения, а лучшие инженеры из команды уже будут работать в другой компании с такими же «печеньками в офисе и на полной удаленке».

Меня зовут Тимур Исхаков, я технический директор в Ak Bars Digital. Мы отвечаем за развитие ИТ Ак Барс Банка. 

В 2016 году, когда наша компания стартовала, мы сразу «пошли» в цифровизацию и аджайл. Начали со Scrum, которым уже тогда никого было не удивить: кросс-функциональные команды, Product Owners, пользовательские истории — выращивали продуктовую разработку. 

С 2018 года мы стали работать по SAFe: стримы, каналы, бизнес-юниты — вот это вот всё. И как результат — в 2021 году Ак Барс Банк занял 4 место в рейтинге самых инновационных банков России, а мобильное приложение Ак Барс Онлайн 3 года подряд входит в ТОП-3 лучших мобильных банков по версии Markswebb. 

В статье расскажу: зачем и как мы пришли к SAFe, как формировались стримы, о плюсах и минусах вариантов ориентации стримов на структуру бизнес-дирекций, ориентации на ИТ-продукт или на бизнес-продукт. В статье будет достаточно много терминов, связанных с SAFe — предполагаю, что вы с ними знакомы, хотя небольшие пояснения все же оставлю.

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

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

Меня зовут Дмитрий Серов, и я являюсь руководителем направления промышленного интернета вещей в компании UMNO.digital. В ИТ-индустрии я работаю около 20 лет, последние 5 из которых занимаюсь проектами IIoT в таких отраслях как телеком, сельское хозяйство, ЖКХ, сейчас развиваю это направление для ж/д и промышленных предприятий.

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

Привет, Хабр! Меня зовут Сергей Обухов, я – технический директор Группы компаний X-Com. Сегодня я поделюсь нашей болью и опытом переезда корпоративного мессенджера. Судя по всему, в такой ситуации сегодня может оказаться кто угодно, так что, возможно, наш опыт покажется вам полезен. Под катом — небольшая история о том, как нам отключили Slack, и что происходило с командой, пока мы не перешли в новый корпоративный мессенджер.

Привет! Я — Дарья, руководитель проектов в Uzum Data. В этой статье поделюсь с вами опытом работы с OpenSource SMS‑шлюзом Jasmin: какие у нас были требования, с какими препятствиями столкнулись, как выбирались из трудностей.

C чего всё началось

Нам нужно было подключить новый канал смс‑рассылки, т.к. по старым каналам мы начали упираться в лимиты. Новый канал представляет собой коммуникацию с использованием A2P каналов, то есть коммуникации от бизнеса пользователям. A2P используется как в маркетинге, так и в сервисах: для подтверждения покупки, авторизации, напоминаний, рассылок и т. д.

У многих людей периодически возникают проблемы с коммуникацией, и они не понимают, почему это происходит. При этом бывает, вы чувствуете, что в коммуникации что-то не так еще до того как она «сломается».

Поговорим о тех вещах, которые многие и так умеют делать, но не осознают и не управляют этим осознанно. Поможет нам в этом Артур Орлов из компании ATI.SU. Он начинал карьеру с fullstack разработчика в 2004 году. Потом работал тимлидом, agile коучем и ICF-коучем. В настоящий момент он коуч по корпоративной культуре — помогает командам и компании выращивать здоровую культуру. Для этого нужно выработать алгоритм эффективной коммуникации, наладить процессы коммуникации и вообще определиться, что с ними делать. Найти какие могут быть потери, определить функции и составить протокол общения. Всё это, даже неподготовленному человеку, позволит увидеть в обычной коммуникации немного больше.

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

Меня зовут Вика Плешкова, я руководитель IT PM в Lamoda Tech. В этой статье я хочу поделиться нашим опытом перехода к кросс-функциональным продуктовым командам — VTeams. А еще я расскажу, каких успехов мы добились на примере большого кейса по открытию второго склада.