Управление проектным бизнесом

Что делать, когда нельзя но хочется? Критическая цепь говорит "Если хочешь выполнять все проекты вовремя, то сделай чтобы у тебя не было плохой многозадачности". Это конечно хорошее правило, но что делать когда: 1. Компания сервисная (проекты под заказ, типа: Проектирование, ИТ) 2. Сроки диктует Заказчик. 3. Мы берем все контракты которые можем взять. 4. Присутствует сезонность,то есть "то густо то пусто". Таким образом получается что: Мы должны взять заказ, но выполнить его в те сроки когда НАМ удобно. То есть "сроки проекта по договору" это не тоже самое что "производственные сроки проекта". Варианты действий: 1. Технология "Плата за выбор", (Почти тоже самое что быструю езду) - можно на 2-3 месяца двинуть, но необходимо просчитать негативные последствия 2. Затягивание сроков заключения договора по юридическим особенностям - сдвиг на 1-2 месяца 3. На этапе заключения договора сразу планируется увеличение сроков проекта без увеличения стоимости, чтобы задержать начало проекта. 4. Дисконт за сдвижку сроков в то место где удобно выполнить. 5. Явно прописать санкции (в увеличении времени) за любое нарушение условий любых согласований.. 6. Если Заказчик готов этапной поставке, то увеличить срок x2 и микшировать проекты по спринтам применяя дозировку (фокусировку на каждом проекте с быстрой поставкой, и перерывами) Коллеги, а какие ещё варианты сдвижки сроков в нужные производственные даты вы видите? И какие из предложенных вариантов применяли?

Плохой, Хороший и Отличный Руководитель проекта В книге я в прологе написал о Дао Управления: Когда познаешь Дао Управления, ты перестанешь нуждаться в Управлении. Все будет работать именно так, как нужно. (А как не нужно, работать не будет) А тут вопрос по этой теме пришёл: "А как Метод рекомендует действовать, когда ситуация постоянно меняется?" Поэтому исходя из базовой посылки о Дао Управления, даю определения: Плохой руководитель проекта умеет договариваться о переносе сроков, когда понимает, что проект выпал из графика. Он часто практикует формальный подход к управлению. Можно услышать фразы "так звёзды сошлись", "не получилось". Я называю его плохим управленцем, но он отличный политик. Потому, что "спустить на тормозах" проблему - для этого нужно мастерство. Хороший руководитель проекта умеет уложить проект в график даже если есть проблемы на проекте. Такой управленец умеет решать проблемы, по мере их поступления. Он активно реагирует на индикаторы, умеет договариваться с командой проекта так, что не приходится играть в политику. Однако навыки политических игр и переговоров позволяют ему уверенно достигать поставленных целей. Отличный руководитель проекта создает такую ситуацию, при которой не требуется решать проблемы на проекте, и проект попадает в график. Когда он в роли хорошего руководителя уже научился спасать, то ему больше не хочется это делать, поэтому он делает проактивное выстраивание ситуации при которой результат достигается без воздействий. #метод

Что-то редко стал писать, новостей мало. Но тут нашел интересное, если вы делаете стартап или новый продукт. Обычно при разработке новых (ИТ-) продуктов есть анализ альтернатив: - конкуренты - решения-заместители (см. JTBD) С точки зрения реального бизнеса, если нет сильного ИТ-отдела, то часто выбор стоит между "Покупать у поставщика А или покупать у поставщика Б". Но сейчас с развитием нейронок появился третий выбор: - Сделать с ИИ-агентом. То есть компании "без ИТ" и "с ИТ" сравнялись в выборе: - делать свое , или - покупать А значит при запуске нового ИТ-продукта, нужно задать первый вопрос: Почему клиенты будут У НАС покупать, а не создать своё с нейронкой?

Про нейронки и разработку программного обеспечения Чем больше я использую ИИ-агентов (модели) тем больше убеждаюсь, что Метод с Правилами Документирования и Правилами непрерывного проектирования становится становится не просто рекомендацией, а жизненно необходимым. И вот почему: 1. ИИ-агент работает, как я на проекте, который первый раз вижу. Он видит целевую часть для внесения изменений, но не понимает её. Чтобы понять он начинает шерстить весь проект, чтобы понять "Что значит эта функция" , "К чему относится это имя", "Из чего состоит та или иная сущность". И проблема не в том, что жгутся токены, а том что это ДОЛГО. Иногда быстрее руками все сделать чем ждать пока ИИ-агент построить у себя контекст. 2. Второй аспект в том, что код не описывает "Почему, так сделано", модульные тесты фиксируют поведение "должно работать так" , а "почему?" - на этот вопрос в коде нет ответа. Как результат ИИ-модель начинает пробивать дыры в архитектуре. Так бывает когда главный архитектор покинул компанию, а вместо него остались профессионалы, но никто не знает Замысел. И получается, что формально "Задача выполнена", а в реальности это уже костыли. И вроде код работает, и тесты есть, но... это костыли и со временем они будут только наслаиваться, пока эту махину нельзя будет поддерживать. Поэтому важно: 1. Проектировать в Вики. Думать в вики. Писать туда что хотел автор, основной замысел. 2. Регулярно обновлять документацию. "Замысел - архитектура" с описанием почему так. 3. При завершении задачи писать отчёт "Как именно сделано" , Пусть это будет "дублирование из вики", но чтобы поставить новое задание ИИ-агенту нужно чтобы живой исполнитель, сам понял "как это примерно работает". Нейронка может писать хороший код, правильный. стерильный. Но если в проекте есть "хаки" (потому что так работает быстрее или проще поддерживать) - то всё ломается. Самое интересное, что мы сейчас возвращаемся в 1970 код и статье Винстона Ройса , основная мысль которой "Чтобы быстрее за