1. Модель проектного управления по ТОС
1.1. Модели вообще
1.1.1. Сноуден
1.1.1.1. Он молодец правительтсво США злыдни его надо освободить
1.1.1.2. ОН враг народа (мириканского)
1.1.1.3. Вообще не важно выдадут его или нет американское правительство делает секретные законы, что означает что оно не подчиняется никому и вообще это не демократия, а махровый паразитизм
1.1.1.4. Шумиха раздута для того, чтобы оправдать высокие расходы на систему слежки. Похвастаться что все работает, а для отвода глаз показать как все возмущены
1.1.2. Якунин
1.1.2.1. Злые хакеры влезли без спросу Якунин ни при чем РЖД будет дальше управляться также
1.1.2.2. Имеет смысл посмотреть как это связано с объединение ЖД белоруссии и казахстана, кто будет управлять объединенной компанией. Зачем вообще все эти нападки на его дачи
1.1.2.3. Во время встречи с путиным он ел глухаря, типа ездил на охоту. Они друганы, следовательно, все у путина под контролем. Хакеры ни причем, они карманные. Это как вначале фильма должен быть трах и выстрелы, чтобы привлечь внимание. Их дело сказать, что в объединенной компании главным будет тот с кем путин будет есть рябчиков.
1.1.3. Управление проектами
1.1.3.1. Будем балансировать сроки бюджет и спецификацию. Изучать талмуд ПМБОК и оценивать риски. Потом будем констатировать что они произошли и пополнять статистику неуспехов проектного управления
1.1.3.2. Будем искать людей звезд и платить им офигенную зарплату и они нас спасут
1.1.3.3. Главное в управлении неопределеностью заложить буфер и грамотно его использовать. Если они расходуются, то нужно разрабатывать дополнительные меры выделять бюджеты. И это норамльно у нас не завод а проекты
1.1.3.4. Вообще никакие это не проекты а реальный завод, просто нормативы отклоняются на 20-50% у разных исполнителей, но если считать по среднему то все укладывается в производственную систему
2. Как натягивается модель ТОС (ССPM) на:
2.1. Сайтостроение или внедрение 1С
2.1.1. Задачи в проекте одна за другой. Общий буфер в конце. Следим чтобы вовремя перейти с одного этапа на другой
2.2. Магазиностроение
2.2.1. Есть у проекта две ветви строительная и подбор персонала, которые должны сойтись к открытию. Наше дело либо одну из них сократить чтобы отслеживать только оставшуюся либо поставить буфер перед открытием...
2.3. SAAS сервис
2.3.1. Чтобы новые фичи вовремя попадали в релиз гораздо важнее проработать ТЗ. Мой опыт показывает, что количество ошибок снижается в среднем с 50 за фичу до 3-5. Стомость одного аналитика в разы меньше чем стоимость команды занимающейся переделками и костылями
2.4. ИТ инфраструктуру
2.4.1. Итерации програмиирования делаются в своем ритме 2 недели мы туда не лезем. Главное чтобы этот ритм не сбивался промежуточными релизами и прочими вспомогательными работами ИТ-инфраструктуры. Конечно хорошо бы поиграть скоростью команд выраженных в сторипоинтах, но если ИТ не будет справляться с тем количеством релизов, зачем напрягать програмиистов?
3. Проекты Производство или Услуги
3.1. Какие процедуры для ИТ если проектное управление
3.2. Какие процедуры если производство
3.3. Какие процедуры если услуги
4. Сложности ИТ инфраструктуры
4.1. Многозадачность админов
4.2. Много "цехов"
4.3. Высокая нестабильность оценок работы
4.4. Скорость работы админов отличается
5. Как решитть проблему "не хватает программистов/админов?"
6. Выводы
6.1. Обещанные тезисы
6.1.1. Хватает экселя
6.1.2. Программистов не трогайте
6.1.3. Главные показатели на узком звене - виртуальный барабан
6.1.4. Обслужить всех невозможно. Для этого нужно проектировать услугу, а не производство
6.1.5. Главное ответ на вопрос "зачем людям вдруг стать работать эффективнее? оно им надо?"
6.2. Стратегия изменений
6.2.1. Есть "транспортный цех" отлично - значит все его обвиняют. Это еще лучше
6.2.2. Наводим порядок и предлагаем всем метрики по которым оценивается а потом и планируется работа
6.2.3. Переходим из области планирования проектов к приоретизации оцереди проектов
6.2.4. Транслируем приоритеты в остальные департаменты