— Почему был выбран именно CMMI?
Наше руководство решило, что нам это нужно. Какие у них тогда были соображения — я не буду предполагать.
Насколько я помню, тогда же рассматривался вариант OPM3. Но от него отказались, вероятно потому, что CMMI, в принципе, включает и управление проектами. К тому же, видимо, на рынке клиентов спроса на OPM3 не было :). Точно не помню сейчас OPM3 (помню, что много общего), но CMMI включет помимо Organizational Project Management еще и Organizational Process Management, Engineering и Support области.
— Не шашечки ли это — «уровень зрелости в целом», вместо «уровня зрелости вида деятельности».
CMMI имеет варианты для Development, Services, Systems (и даже People). CMMI for Development, о котором и идет речь, рассматривает необходимые условия для работы IT подразделения, то есть «уровень зрелости IT подразделения/компании». Но я бы все-таки определяла немного по-другому: уровень зрелости управления IT подразделением/компанией.
Управление рисками — не самоцель, это инструмент для про-активных действий, для предотвращения возможных проблем, вместо тушния пожаров. Это инструмент коммуникации с руководством компании и клиентом.
В статье я привожу примеры того, с чем я сталкивалась. И они не радужные. Они как раз свидетельствуют о наличии ненужной борократической процедуры — наличия регистра рисков с банальными проблемами.
Сейчас передо нами (в нашей компании) стоит задача — устранить ненужную бюрокаратию и минимизировать «пожары» за счет «проактивного» менеджмента.
За аудитом последовало исследование, тренинг и workshop-ы, изменились (стали жесче и конкретнее) требования к процессу управления проектами и определены точки контроля корректирующих действий.
Эта статья как раз и является обобщением наших ресёрчей и брейнстормингов. Сейчас мы пытаемся внедрить те рекомендации, которые я описываю. Последующий контроль корректирующих действий покажет есть ли эффект.
Обязательно поделюсь результатами.
О да, знакомо. Только Вася ему не сделает качество, которое он хочет. И в итоге он будет недоволен. Хотя, если Вася умный мужик, то он сделает то, что может и убедит, что именно это и нужно было :). А потом будет выманивать по баксу за каждый дополнительный чих.
Не уверена, что мой совет попадет в цель, но все же: попробуйте выявить наиболее, принципиально важные требования к будущему продукту, чтобы быстро и грязно (но с «заглушками», чтобы потом если что доделывать) сделать ту функциональность, которая сейчас этому заказчику жизненно важна. Не нужно думать над уровнями сложности пароля, поддержки кучи платежных систем и пр.
Выявить ту самую болевую точку сложно, но можно. (Можно у него попросить пример партнерки которая ему нравится и узнать чем именно она ему нравится).
И так потихоньку, по запчастям (возможно, потом окажется, что у него есть сотня-другая баксов, которые он сначала не был готов выкладывать) доводить его до полного удовлетворения.
И еще, не надо говорить с ним терминами ТЗ, архитектура, безопасность и пр. Ему надо показать, сколько он сохранит, заработает или потеряет пользователей, траффика и пр. (читай: «денег») при добавлении-отключении тех или иных «фишек».
А в целом, чтобы «делать всё качественно, по стандартам, с анализом требований, составлением юзкейсов и ТЗ» нужно выходить на другой уровень фрилансерства. А для этого нужно постигать хитрости продаж и бизнесс анализа.
«календарный план уходит в прошлое»?
по нашему опыту, большинство клиентов интересуют сроки в первую очередь, ну и конечно, чтобы поменьше людей привлекалось — вседь это влияет на стоимость заказа. В таких случаях без хорошей разбивки (breakdown) и календарного плана с учетом зависимостей никуда. Как еще объяснишь заказчику, почему так долго или так дорого?
«Проект, в котором от начала до конца жил календарный план» — в коммерческих проектах он никогда не был и не будет одим и тем же. Он должен жить вместе с проектом. И возможно это только если делать достаточно детальный WBS (почему бы не основывать его на архитектуре), и связывать работы зависимостями.
Кстати, у заказчика не всегда есть понимание того, что для него первостепенно важно, а что — нет, но намного чаще есть какие-то временные ограничения.
Обсуждение календарного плана (и его поправок на изменения внешней среды) с заказчиком, покажут достаточно быстро, какие функции системы критичны для него а какие — могут подождать.
Наше руководство решило, что нам это нужно. Какие у них тогда были соображения — я не буду предполагать.
Насколько я помню, тогда же рассматривался вариант OPM3. Но от него отказались, вероятно потому, что CMMI, в принципе, включает и управление проектами. К тому же, видимо, на рынке клиентов спроса на OPM3 не было :). Точно не помню сейчас OPM3 (помню, что много общего), но CMMI включет помимо Organizational Project Management еще и Organizational Process Management, Engineering и Support области.
— Не шашечки ли это — «уровень зрелости в целом», вместо «уровня зрелости вида деятельности».
CMMI имеет варианты для Development, Services, Systems (и даже People). CMMI for Development, о котором и идет речь, рассматривает необходимые условия для работы IT подразделения, то есть «уровень зрелости IT подразделения/компании». Но я бы все-таки определяла немного по-другому: уровень зрелости управления IT подразделением/компанией.
В статье я привожу примеры того, с чем я сталкивалась. И они не радужные. Они как раз свидетельствуют о наличии ненужной борократической процедуры — наличия регистра рисков с банальными проблемами.
Сейчас передо нами (в нашей компании) стоит задача — устранить ненужную бюрокаратию и минимизировать «пожары» за счет «проактивного» менеджмента.
За аудитом последовало исследование, тренинг и workshop-ы, изменились (стали жесче и конкретнее) требования к процессу управления проектами и определены точки контроля корректирующих действий.
Эта статья как раз и является обобщением наших ресёрчей и брейнстормингов. Сейчас мы пытаемся внедрить те рекомендации, которые я описываю. Последующий контроль корректирующих действий покажет есть ли эффект.
Обязательно поделюсь результатами.
Не уверена, что мой совет попадет в цель, но все же: попробуйте выявить наиболее, принципиально важные требования к будущему продукту, чтобы быстро и грязно (но с «заглушками», чтобы потом если что доделывать) сделать ту функциональность, которая сейчас этому заказчику жизненно важна. Не нужно думать над уровнями сложности пароля, поддержки кучи платежных систем и пр.
Выявить ту самую болевую точку сложно, но можно. (Можно у него попросить пример партнерки которая ему нравится и узнать чем именно она ему нравится).
И так потихоньку, по запчастям (возможно, потом окажется, что у него есть сотня-другая баксов, которые он сначала не был готов выкладывать) доводить его до полного удовлетворения.
И еще, не надо говорить с ним терминами ТЗ, архитектура, безопасность и пр. Ему надо показать, сколько он сохранит, заработает или потеряет пользователей, траффика и пр. (читай: «денег») при добавлении-отключении тех или иных «фишек».
А в целом, чтобы «делать всё качественно, по стандартам, с анализом требований, составлением юзкейсов и ТЗ» нужно выходить на другой уровень фрилансерства. А для этого нужно постигать хитрости продаж и бизнесс анализа.
по нашему опыту, большинство клиентов интересуют сроки в первую очередь, ну и конечно, чтобы поменьше людей привлекалось — вседь это влияет на стоимость заказа. В таких случаях без хорошей разбивки (breakdown) и календарного плана с учетом зависимостей никуда. Как еще объяснишь заказчику, почему так долго или так дорого?
«Проект, в котором от начала до конца жил календарный план» — в коммерческих проектах он никогда не был и не будет одим и тем же. Он должен жить вместе с проектом. И возможно это только если делать достаточно детальный WBS (почему бы не основывать его на архитектуре), и связывать работы зависимостями.
Кстати, у заказчика не всегда есть понимание того, что для него первостепенно важно, а что — нет, но намного чаще есть какие-то временные ограничения.
Обсуждение календарного плана (и его поправок на изменения внешней среды) с заказчиком, покажут достаточно быстро, какие функции системы критичны для него а какие — могут подождать.