Шаг назад и … шаг назад (классификация внутренних проектов)

Краткое содержание первой серии — в ней рассказывалось о ведении проектов методом роевого интеллекта (Swarm intelligence).

Роевой интеллект (Swarm intelligence) как метод управления проектами (анти-утопия)

Не совсем буря, но волна народного гнева смела в комментариях хрупкие мостки логики. И основной посыл был: хотим работать в Agile!
Тучи начинали сгущаться над головой великого комбинатора.

— Одну минуточку, — сказал Остап, чарующе улыбаясь, — маленькая заминка.

Тут очнувшийся Ипполит Матвеевич, разбрызгивая слюну, ворвался в разговор.

— Позвольте! — завопил он. — Почему комиссионный сбор? Мы ничего не знаем о таком сборе! Надо предупреждать. Я отказываюсь платить эти тридцать рублей!

— Хорошо, — сказала барышня кротко, — я сейчас все устрою.

Итак, вернемся на шаг назад и приступим к классификации внутренних проектов.

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

Классическая форма тройственной ограниченности (впоследствии в нее добавили еще парочку ограничений, но название оставили прежним)

Позволю себе предположить, опираясь на свой опыт, что и управление проектом имеет три вектора — неопределенность, ваши полномочия, заинтересованность команды в успехе, где каждый из векторов оказывает влияние на метод ведения проекта. Изменение одной силы влияет на другие. Это объясняет те случаи, когда типично водопадный проект вдруг пошел по пути Agile. А просто всем пообещали премию.

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

1. Начнем с апологетов Agile, чтобы отпустить их пораньше.
Ну и просто по алфавиту.

Попытка вести все проекты по Agile подозрительно напоминает "кукурузные времена" Хрущевской оттепели. Ну не вырастет кукуруза на вечной мерзлоте, а там, где условия есть — самое милое дело.

Собственно сам Agile это лишь манифест, методы ведения проекта могут быть Scrum, Lean software development, Extreme programming, Kanban, но все они предполагают гибкость разработки и некоторую некомпетентность заказчика.
Кстати, пытливые умы обратят внимание на некоторый факт.
Канбан празднует свой 60 летний юбилей. В былые годы он был бы уже на пенсии, а сейчас благодаря нашему правительству пользуется привилегиями предпенсионера.
Программированию тоже немало лет. И вот эти две жабы два одиночества встретились. Откуда взялся расцвет и мировая популярность в столь преклонном возрасте? Ответ прост — доткомы. Именно веб разработка дала такой толчок гибким методам программирования.
И в них (этих методах) гораздо больше от отделов продаж, чем от программистов.
Программисты то всегда люди конкретные, это у продажников 2х2 может быть равно и 3 и 5, а если прикрыть двери то и 6.
На профильных сайтах то тут то там появляются статьи как ужасен Scrum. Тот же Хабр переполнен статьями о возврате к подробным тех. заданиям.
Это не ностальгия, а нормальный ход истории. Мода на гибкую разработку проходит.
Лопнет ли этот пузырь Scrum, как лопнули доткомы, как взлетал и падал биткоин, мы увидим в ближайшее время.
Скорее всего он займет свою нишу и продолжит спокойное существование. А пока:

Если неопределенность невелика, а команда проекта ну просто коллектив единомышленников, то это типично Agile случай.

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

Раз уж зашла речь о временах СССР, то от Agile
2. переходим к Waterfall.

Он кстати в реалиях 1С возможно еще более распространен.

Это многочисленные ФЗ-ххх, изменения ставок НДС, форм отчетности т.п.
Когда неопределенность равна нулю, а полномочия велики, заинтересованность участников не имеет значения, спокойно обведите в календаре даты. Все сработает.

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

Старый добрый Waterfall. Те, кто могут себе это позволить, наигравшись с Agile возвращаются в его лоно с удовольствием.

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

Иначе мы попадаем в

3. проект типа штурмовщина.

Неопределенность средняя, полномочия — никаких, заинтересованность команды нестабильна (подогревается волшебными пенделями извне).

Во времена того же СССР была очень распространена пословица: "Чтобы корова давала больше молока и меньше ела — ее надо меньше кормить и больше доить."

При откровенно слабом, но непомерно влюбленном в себя руководстве подход именно такой.

Это самый тяжелый и к сожалению самый распространенный метод ведения проекта.

Собственно, и вести его вам нужно как корабль среди штормового моря.

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

Рядом с этим типом проектов, очень рядом находится

4. проект типа «показуха».

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

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

"Заменим всех бухгалтеров роботами!", "Применим ИИ к водителям погрузчиков!" ,"Каждой продаже по блокчейну!" 

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

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

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

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

Это ведь машина не для езды, а для гордости.

И обычно тут же находится тип проекта, когда и неопределенность — 100%

5. Это «сказочные» проекты. От слов "пойди туда не знаю куда, принеси то не знаю, что…" разумеется

"Даешь цифровизацию!","Перейдем планирование по схеме Бойля-Мариотта", "Телепортацию в каждый отдел!".

Чего только начальники непрофильных отделов не прочитают ВКонтакте и не пообещают на совещаниях.

Ведущего такой проект наилучшим образом описал Ходжа Насреддин в истории об осле и падишахе.
Даже добавлять особенно нечего. Запрашивайте финансирование, вычерчивайте графики выполнения к 2025 году. Стоп. Эта дата уже зарезервирована правительством. Тогда к 2026 году.

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

В длительной перспективе, последние три варианта — бесперспективны.

Как говорил один очень уважаемый мной кадровик: «Когда компания работает в режиме вечного аврала, остаются те, кому на все наплевать».

Но в краткосрочном варианте вполне возможны. Принимайте их спокойно, как часть большой работы.

Совсем на отшибе стоят проекты, где заинтересованность команды отрицательная

6. В моей классификации – тупиковые.
Пример: вы автоматизируете работу сотрудника, который, что называется ловил рыбку в мутной воде. Завышал тарифы, брал откаты, усушка, утруска и т.п.

В более мягком варианте просто борется за свое право смотреть котиков в инстаграмме.

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

От меня рекомендаций не ждите.

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

И только сейчас, на точке до которой половина и не дочитала, мы пришли к проектам, к которым

7. применим роевой интеллект.

Чуть выше среднего неопределенность, достаточно большие права и заинтересованность команды.

То, о чем была прошлая статья.

У роевого интеллекта, к слову, так же, как и у Agile есть достаточно большое количество методов реализации.

Самые распространенные из них три :
7.а  Метод роя частиц
Его отличительные особенности выражаясь языком плаката:
– Все агенты должны избегать пересечения с окружающими их агентам;

– Каждая частица должна корректировать свою скорость в соответствии со скоростями окружающих её частиц;

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

Области применения: Биоинженерия, биомеханика, биохимия; Задачи машинного обучения; Задачи оптимизации функций многих параметров и топологий; Область проектирования.
В проектах программирования это скорее задачи оптимизации и автоматизации понятной рутинной работы пользователей.
7.б  Муравьиный алгоритм (самый известный и применяемый в решении различных прикладных задач, классика — Задача коммивояжёра)


Концепция алгоритма заключается в способности муравьев находить кратчайший путь крайне быстро и адаптироваться к различным внешним условиям. При движении каждый муравей помечает свой путь феромоном, что в дальнейшем используется другими муравьями. Это и есть простой алгоритм одного агента, который в сумме всех агентов колонии позволяет находить кратчайший путь или изменять его при обнаружении препятствия.
Преимущества данного метода:  Достаточно эффективен для TSP (Traveling Salesman Problem) с небольшим количеством узлов; Используется приложениях, которые могут адаптироваться к изменениям; Благодаря памяти всей колонии и случайному выбору пути не так сильно подвержен неудачным первоначальным решениям.
Области применения: Расчеты компьютерных и телекоммуникационных сетей; Задача коммивояжёра; Задача раскраски графа; Задача оптимизации сетевых трафиков.
В проектах программирования это задачи выбора из различных вариантов решения, когда возможны варианты тестовой эксплуатации

7.в Алгоритм искусственной пчелиной колонии
Основывается на существовании двух видов пчел: пчелы-разведчики и пчелы-рабочие. Первые проводят исследование территории, окружающей улей, на предмет наличия нектара. По возвращении в улей, пчелы-разведчики сообщают информацию о количестве нектара, направлении его расположения и расстоянии до него. Далее, в наиболее подходящие области вылетают рабочие, причем, чем больше нектара в данной области, тем больше пчел вылетает в нее. 
Преимущества данного метода:  Возможность эффективного разделения на параллельные процессы; Высокая скорость работы.
Области применения: Оптимизация управления; Оптимизация классификаторов..
В проектах программирования обязательное наличие команды тестировщиков (возможно из числа наиболее подготовленных пользователей)

Математический аппарат я с общего разрешения приводить не буду.

Хотя некоторые формулы очень приятны глазу, например: 

vZ77;v+rnd()(Pbest-x)c1+rnd()(gbest-x)c2

или 

 

О графиках я вообще молчу

В статьях о Канбан я тоже не наблюдал формул Сигео Синго и Ясухиро Мондена.

Заинтересовавшиеся могут легко найти всю доступную информацию в сети.

Вполне возможно, что кто-то дополнит или полностью отринет мою классификацию проектов.

Это можно сделать в комментариях.

Статья не призвана никого обидеть. 

Все события и герои вымышлены. Любые совпадения с реальными личностями случайны.

Завершить же ее я хотел бы очень известной цитатой:

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

        Молитва немецкого богослова Карла Фридриха Этингера (1702— 1782).

Разбирайтесь с вектором сил перед тем, как настроить паруса проекта.

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

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

Я из того поколения, для которого друг это человек, который поделится с тобой своим запасом воздуха, это немного отличается от "ставящий лайки"