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

03.12.18

Анализ и управление - Управление проектом

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

Краткое содержание первой серии - в ней рассказывалось о ведении проектов методом роевого интеллекта (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).

 

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

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

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

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

Agile управление проектами канбан

См. также

Анализ & Управление в ИТ-проектах, 30 мая - 1 июня 2024 г., Санкт-Петербург

Анализ и управление Управление проектом Анализ и проектирование ИТ-систем Мероприятия Россия Платные (руб)

Практическая конференция для аналитиков и руководителей проектов 1С. 30 мая - 1 июня 2024 г. Санкт-Петербург, отель Park Inn by Radisson Pribaltiyskaya, ул. Кораблестроителей 14

30000 руб.

27.05.2023    15713    1    0    

5

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Управление проектом Внедрение ИТ-системы Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    12329    ASchekachev    36    

47

Организация работы внутренней команды 1С с помощью Канбан

Управление проектом Управление командой Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    4904    stnslv    5    

23

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Управление командой Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    3479    andironenko    2    

28

На что похож ваш продукт: на Аквариум или на Муравейник? 

Управление проектом Бесплатно (free)

Давайте поиграем в метафоры в лучших традициях экстремального программирования. А заодно проведем новогодний конкурс - на лучшую метафору для автоматизированного продукта

27.12.2022    2227    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    2900    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Внедрение ИТ-системы Управление проектом Управление командой Управление ИТ-подразделением Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

09.09.2022    8672    biimmap    79    

65

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Анализ и проектирование ИТ-систем Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    11452    Evil Beaver    17    

108
Вознаграждение за ответ
Показать полностью
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. MariaTemchina 1602 03.12.18 10:29 Сейчас в теме
Спасибо, прочитала с большим удовольствием!
Olga_aku; +1 Ответить
2. capitan 2362 03.12.18 11:18 Сейчас в теме
(1)Мария, спасибо за отзыв!
Для меня ваше мнение очень важно.
3. Timur.V 67 03.12.18 14:01 Сейчас в теме
"Чтобы корова давала больше молока и меньше ела - ее надо меньше кормить и больше доить."

Agile, Канбан - позволяют увеличить удои надои молока.
4. capitan 2362 03.12.18 14:09 Сейчас в теме
(3)
Agile, Канбан - позволяют увеличить удои надои молока

собственно чуть выше написано каким путем )
Они могут общую скорость разработки увеличить, но никак не количество написанного кода.
5. creatermc 26 03.12.18 14:15 Сейчас в теме
Достаточно на профессиональном уровне все описано, что бы ничего не пропустить надо будет подготовиться.
8. capitan 2362 03.12.18 15:20 Сейчас в теме
(5)Вот уже и Ричард Гир кодирует в 1С )
К чему подготовиться недопонял ?
6. acanta 03.12.18 14:34 Сейчас в теме
Гибкая разработка идеальна, когда у разработчика (программиста) есть чрезвычайно глубокое понимание предметной области. Проработал на родном предприятии на всех должностях, ушел(а) в декрет/ на повышение квалификации работать программистом, написал программу-скелетик, вернулся, внедрил по Agile c доработками по всем пожеланиям всех пользователей.И остался сидеть в уютном кабинете плевать в потолок и лайкать котиков отправился на вольные хлеба предлагать ее всем желающим, заодно привлекая народ в свое болото продвигая и осваивая эту сферу бизнеса с разных сторон.

ТЗ - это конспект для дипломной работы / краткое содержание Санта-барбары введение в предметную область, написанное языком понятным программистам/ методистам /заказчику хоть кому-нибудь из участников процесса.
Maks_Alexey13; A_Max; +2 Ответить
9. capitan 2362 03.12.18 15:23 Сейчас в теме
(6)Все точно. Хотелось бы только увидеть человека который поработав на всех должностях ушел работать программистом )
13. capitan 2362 03.12.18 16:09 Сейчас в теме
(9)ну дела. Здесь же был плюс) Куда смотрит модератор )
7. Valerych 03.12.18 14:39 Сейчас в теме
Каскадная модель (англ. waterfall model, иногда переводят как модель «Водопад»).
В качестве источника названия часто указывают статью, опубликованную У. У. Ройсом (W. W. Royce) в 1970 году; при том, что сам Ройс использовал итеративную модель разработки.
В 1970 году в своей статье Ройс описал в виде концепции то, что сейчас принято называть «каскадная модель», и обсуждал недостатки этой модели. Там же он показал как эта модель может быть доработана до итеративной модели.

Начиная с PMBOK 4-й версии удалось достичь компромисса между методологами, приверженными формальному и поступательному управлению проектом, с методологами, делающими ставку на гибкие итеративные методы. Таким образом, начиная с 2009 года, формально Институтом управления проектами (PMI) предлагается как стандарт гибридный вариант методологии управления проектами, сочетающий в себе как плюсы от методики «Водопада», так и достижения итеративных методологов.

Так получается, что внешне похожий на каскад, но только внешне, подход от PMI (можно PRINCE 2) и является той самой практикой, которую автор мог бы смело вписать в статью под. п.2 вместо более узкого понятия, которое критиковал даже "отец модели каскад/водопад" W. W. Royce.
10. capitan 2362 03.12.18 15:29 Сейчас в теме
(7)не совсем так.
Я как раз написал, что в 1С есть задачи классического водопада.
Пример - обновление форм отчетности,есть четкий срок, четкое понимание ресурсов и четкий прием задачи
Ничего итеративного здесь нет.
Если не накосячить конечно )
11. Valerych 03.12.18 15:45 Сейчас в теме
(10) Обновление форм отчетности это проект?

Выглядит как задача.
Конечно для задачи будут заданы сроки, выделены ресурсы и будет содержание/требования.

Пользуясь Вашей терминологией, так для задач не только ничего итеративного нет, но и ... ничего водопадного/каскадного нет.

Обновление форм отчетности нередко встречается как часть процесса сопровождения.
Попробовал визуализировать процесс состоящий из задач которые не задачи, а проекты, но очень маленькие ... казуистика ...
12. capitan 2362 03.12.18 15:56 Сейчас в теме
(11)
Обновление форм отчетности это проект
если базы 2 то задача, а если 222 то проект наверное
На мой взгляд отличие проекта от задачи и есть развернутое планирование трудозатрат и ресурсов, так то они очень похожи
14. Valerych 03.12.18 16:43 Сейчас в теме
(12) Есть такой сертифицированный PMI Иван Селиховкин, он дает интересную трактовку понятия проект.
https://www.youtube.com/watch?v=ZIAuc_P-rOw

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

Получается, 222 базы требующие обновления форм отчетности, это не 1 проект, не 222 проекта, но это 222 задачи.
Задачи требуют планирования ресурсов, без этого они могут потеряться быть выполнены в самые неожиданные сроки.
15. capitan 2362 03.12.18 17:47 Сейчас в теме
(14)Посмотрю
А переезд офиса в новое здание - это проект?
23. GOshaSaveiko 38 05.12.18 09:59 Сейчас в теме
(15), я бы определил проект как временное мероприятие (имеющее дату начала, окончания) и совершенно определенную уникальную цель (не делалось ранее) и требующий организационных усилий. И так как переезд офиса в новое здание у вас не каждый день бывает, каждый раз разный, требует разного подхода и решений. То да, это проект.
Если бы вы занимались этим каждый день, например перевозили разные компании по одному и тому же чеклисту - это бы стало процессом.
16. capitan 2362 03.12.18 17:54 Сейчас в теме
(14)
высокую степень неопределенности
и вот это пока тоже не нравится
Совершенно не факт, что в проекте должно быть непонятно что, хоть бы он и по аджайл шел
Вспоминается ...
Купили как-то американцы у нас МИГ-29.Перед отправкой весь
его осмотрели-самолет как самолет,все на месте.Разобрали,перевезли
к себе.Собрали,смотрят-паровоз.Снова собрали-разобрали-опять паровоз!
В третий раз разобрали собрали-снова паровоз.Ничего понять не могут.
Вызывают одного из наших техников,спрашивают:"В чем дело?"А он им
отвечает:"Поставьте мне 3 ящика водки и зайдите через неделю..."
Приходят американцы через три недели,смотрят-стоит МиГ-29!Спрашивают
они нашего техника:"Как же ты его собрал?"А он им отвечает:"В инструкции,
внизу,мелкими буквами написано:"После сборки-обработать напильником!"
www.anekdot.ru ©
17. Valerych 03.12.18 18:28 Сейчас в теме
(16) Насчет неопределенности позвольте привести ссылку с рассуждениями Ивана Селиховкина.
https://infostart.ru/public/870848/
18. capitan 2362 03.12.18 19:31 Сейчас в теме
(17)Не очень с ними согласен. И понятие неопределенности тоже несколько загадочное.
Вот будете обновлять 2 базы и тоже есть неопределенность, может свет рубанут ?
Поэтому я бы представлял водопадный проект как то что можно нарисовать в Project - как классику: ресурсы, временная шкала, диаграмма Ганта )
А неопределенность оставим стадиону Зенит, как Иван справедливо отметил
20. Valerych 03.12.18 20:27 Сейчас в теме
(18)
Поэтому я бы представлял водопадный проект как то что можно нарисовать в Project - как классику: ресурсы, временная шкала, диаграмма Ганта )


Вы почти процитировали PMBOK.
Но современный PMBOK все же голосует за гибридные методы управления проектами (почти 10 лет уже как), т.е. водопад усиленный итеративными методами.

И да, п.2 как-то мощнее звучит, если заменить водопад на "методы классического проектного управления" :)
(в понимании PMBOK или PRINCE 2 на выбор)
21. capitan 2362 03.12.18 21:45 Сейчас в теме
(20)тут мы вошли в цикл )
19. capitan 2362 03.12.18 19:58 Сейчас в теме
(17)К тому же не забывайте - я говорю о проектах внутренних, там уставы не пишут
22. GOshaSaveiko 38 05.12.18 09:16 Сейчас в теме
У меня несколько иное мнение по поводу неопределенности и Scrum. Scrum хорош именно в условиях неопределенности. Когда четких требований нет, никто не знает как, но есть визионер, который примерно представляет куда надо идти. Скрам позволяет довольно быстро выкатить MVP и улучшать его короткими итерациями. Глупо писать подробное ТЗ, делать большой продукт, а в конце обнаружить, что 80% фич юзерам не надо. И вообще удобнее другой интерфейс и другая архитектура.
25. capitan 2362 12.12.18 16:48 Сейчас в теме
(22)Scrum хорош когда есть неопределенность и есть команда.
Это в 90% случаев не так
Нет команды - нет Scrum
24. FB_1811930315551820 05.12.18 10:30 Сейчас в теме
Прочитал обе статьи и комменты к ним с большим интересом. Потом сел с блокнотом и ручкой, немного подумал... еще раз перечитал обе статьи и отдельные комменты... и примерно понял, с чем не могу согласиться, как практик. Сейчас попробую связно изложить:
1. Автор все-таки недостаточно строг в использовании ключевых понятий. Проект - это не просто задача, алгоритм - это еще не метод, неопределенность не тождественна препятствиям в реализации, команда проекта - не просто совокупность всех вовлеченных в проект работников,ну и еще разное, по мелочам.
2. Если говорить о реализации именно проектов, именно методом роевого интеллекта - то или я так и не понял, в чем принципиальное ПОЛОЖИТЕЛЬНОЕ отличие роевого метода от методов Agile, или этого отличия просто нет. А есть только рекомендация НЕ использовать некоторые наиболее "пафосные" методы Agile - типа доски, стикеров, обязательных ежедневных митингов...
В конечном итоге, держа в уме, что: а) все мы по сути работаем по SCRUM/CanBan/Agile/e.t.c., только не знаем об этом, и б) суть любой стоящей теории может быть изложена так, чтобы ее понял младший школьник, хочу спросить у автора.
Все-таки, с точки зрения практики, в чем суть и новизна (а если усугубить - то и область наиболее эффективного применения) описанного им метода реализации проектов?
26. capitan 2362 12.12.18 17:00 Сейчас в теме
(24)Эта статья вообще классификация проектов и ни в ней ни в предыдущей нет рекомендации не использовать методы Agile и доски стикеры - как просто метод визуализации проекта к SCRUM/CanBan/Agile/e.t.c. имеющий посредственное отношение.

А вот
В конечном итоге, держа в уме, что: а) все мы по сути работаем по SCRUM/CanBan/Agile/e.t.c.
это как раз не так
И больше того скажу - тру программисты типа сеньоров не хотят так работать.
Потому что в существующей реальности - SCRUM/CanBan/Agile/e.t.c. - это просто старт работы без четкого понимания задачи и возможность поменять ТЗ в любой момент на диаметрально противоположное.
https://www.youtube.com/watch?v=UoKlKx-3FcA

А чистое гибкое программирование, как его понимали отцы основатели - это совсем другое
Оставьте свое сообщение