Краткое содержание первой серии - в ней рассказывалось о ведении проектов методом роевого интеллекта (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).
Разбирайтесь с вектором сил перед тем, как настроить паруса проекта.
Если будет интересно, то можно будет сделать еще один шаг назад и поговорить о классификации организаций и как из нее вытекает ведение внутренних проектов.
Интерес на сайте принято выражать плюсами, на запросы добавления в друзья честно, не знаю, как реагировать, и, наверное, не буду.
Я из того поколения, для которого друг это человек, который поделится с тобой своим запасом воздуха, это немного отличается от "ставящий лайки"
