Что делать, когда нельзя но хочется?

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

Это конечно хорошее правило, но что делать когда:
1. Компания сервисная (проекты под заказ, типа: Проектирование, ИТ)
2. Сроки диктует Заказчик.
3. Мы берем все контракты которые можем взять.
4. Присутствует сезонность,то есть "то густо то пусто".

Таким образом получается что: Мы должны взять заказ, но выполнить его в те сроки когда НАМ удобно. То есть "сроки проекта по договору" это не тоже самое что "производственные сроки проекта".

Варианты действий:

1. Технология "Плата за выбор", (Почти тоже самое что быструю езду) - можно на 2-3 месяца двинуть, но необходимо просчитать негативные последствия

2. Затягивание сроков заключения договора по юридическим особенностям - сдвиг на 1-2 месяца

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

4. Дисконт за сдвижку сроков в то место где удобно выполнить.

5. Явно прописать санкции (в увеличении времени) за любое нарушение условий любых согласований..

6. Если Заказчик готов этапной поставке, то увеличить срок x2 и микшировать проекты по спринтам применяя дозировку (фокусировку на каждом проекте с быстрой поставкой, и перерывами)


Коллеги, а какие ещё варианты сдвижки сроков в нужные производственные даты вы видите?

И какие из предложенных вариантов применяли?

Плохой, Хороший и Отличный Руководитель проекта

В книге я в прологе написал о Дао Управления:

Когда познаешь Дао Управления,
ты перестанешь нуждаться в Управлении.
Все будет работать именно так, как нужно.
(А как не нужно, работать не будет)

А тут вопрос по этой теме пришёл: "А как Метод рекомендует действовать, когда ситуация постоянно меняется?"

Поэтому исходя из базовой посылки о Дао Управления, даю определения:

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

Он часто практикует формальный подход к управлению. Можно услышать фразы "так звёзды сошлись", "не получилось". Я называю его плохим управленцем, но он отличный политик. Потому, что "спустить на тормозах" проблему - для этого нужно мастерство.

Хороший руководитель проекта умеет уложить проект в график даже если есть проблемы на проекте.

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

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

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

#метод

В Журнале Управление проектами вышла моя статья "Планирование реализации стратегии".

ТОС определяет термин "Стратегия"

- Ответ на вопрос: "Зачем?"; цель тактики.
Стратегия любого предлагаемого изменения --- это просто цель этого предлагаемого изменения в дереве стратегии и тактики.

Поэтому "Планирование реализации" - это разработка пошагового плана "Как достигнуть Цели" с точки зрения Постоянно процветающей компании.

#новости

Что-то редко стал писать, новостей мало. Но тут нашел интересное, если вы делаете стартап или новый продукт.

Обычно при разработке новых (ИТ-) продуктов есть анализ альтернатив:
- конкуренты
- решения-заместители (см. JTBD)

С точки зрения реального бизнеса, если нет сильного ИТ-отдела, то часто выбор стоит между "Покупать у поставщика А или покупать у поставщика Б".

Но сейчас с развитием нейронок появился третий выбор:
- Сделать с ИИ-агентом.

То есть компании "без ИТ" и "с ИТ" сравнялись в выборе:
- делать свое , или
- покупать

А значит при запуске нового ИТ-продукта, нужно задать первый вопрос: Почему клиенты будут У НАС покупать, а не создать своё с нейронкой?

У нас новый продукт: ReviewTool - среда рецензирования кода для Subversion (SVN).

Ключевые возможности
+ Работа с ветками Subversion.
+ "Нулевая" конфигурация, почти никаких настроек кроме структуры веток и адреса репозитория. Права доступа проверяются самим Subversion
+ Интеграция с любым трекером задач: ссылка на задачу на основе номера ветки (бранча).
+ Конфиденциальность! Никакого облака, только коробочная "on-premise" версия.
+ Языки - русский/английский

Просмотр изменений:
+ Визуализация пробелов
+ Визуализация переносов кода (когда рефакторинг был)
+ Режим IDE и режим общего просмотра.
+ Просмотр сообщений коммита к правкам, чтобы понимать "Что менялось".

Комментирование кода
+ Добавление комментариев к строчкам кода
+ Просмотр предыдущих комментариев с переходом по отметкам
+ Автоматическое формирование отчёта со ссылкой на результаты проверки.
+ Возможность отправки отчета в любой трекер задач через кастомный шлюз.

Система контроля версий Subversion обеспечивает централизованный доступ, неизменность истории и работу с большими файлами из коробки.

ReviewTool - инструмент организации процесса рецензирования кода для Subversion.

Детали и информация по стоимости в личку.
Возможны скидки за ранний доступ.

Примеры экранов ниже.

#reviewtool

Про нейронки и разработку программного обеспечения

Чем больше я использую ИИ-агентов (модели) тем больше убеждаюсь, что Метод с Правилами Документирования и Правилами непрерывного проектирования становится становится не просто рекомендацией, а жизненно необходимым.

И вот почему:

1. ИИ-агент работает, как я на проекте, который первый раз вижу. Он видит целевую часть для внесения изменений, но не понимает её. Чтобы понять он начинает шерстить весь проект, чтобы понять "Что значит эта функция" , "К чему относится это имя", "Из чего состоит та или иная сущность".

И проблема не в том, что жгутся токены, а том что это ДОЛГО. Иногда быстрее руками все сделать чем ждать пока ИИ-агент построить у себя контекст.

2. Второй аспект в том, что код не описывает "Почему, так сделано", модульные тесты фиксируют поведение "должно работать так" , а "почему?" - на этот вопрос в коде нет ответа. Как результат ИИ-модель начинает пробивать дыры в архитектуре. Так бывает когда главный архитектор покинул компанию, а вместо него остались профессионалы, но никто не знает Замысел.

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

Поэтому важно:

1. Проектировать в Вики. Думать в вики. Писать туда что хотел автор, основной замысел.

2. Регулярно обновлять документацию. "Замысел - архитектура" с описанием почему так.

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

Нейронка может писать хороший код, правильный. стерильный. Но если в проекте есть "хаки" (потому что так работает быстрее или проще поддерживать) - то всё ломается.

Самое интересное, что мы сейчас возвращаемся в 1970 код и статье Винстона Ройса , основная мысль которой "Чтобы быстрее запускать программное обеспечение в эксплуатацию - пиши БОЛЬШЕ документов". Разница только в том, что ДОКУМЕНТЫ нужны больше не людям, а ИИ-агентам чтобы они БЫСТРЕЕ находили ответы, и БЫСТРЕЕ писали код, а не "шарились" по исходникам загружая контекст.

#метод #ии