Есть статистика, которая говорит, что более половины SharePoint проектов неуспешны (смотреть тут). С точки зрения бизнеса успешных проектов еще меньше, так как затраты оказываются выше, чем экономический эффект.
Проблема
Многие проекты SharePoint фактически ведутся по процессам разработки программного обеспечения. Все процессы разработки ставят целью разработку нового или доработку существующего ПО. Основные KPI для такого проекта – сроки, функциональный объем и бюджет. Еще говорят о качестве, но качество померить сложно и оно как-то выпадает из основных характеристик.
Негативным эффектом такого способа ведения проектов становится то, что создается много кастомного кода. Ведь нельзя делать разработку, когда нечего положить в систему контроля версий. Обучая разработчиков out-of-the-box функционал, я много раз слышал вопрос о том, что же будет в итоге лежать TFS.
Кастомный код при этом является огромной проблемой, он усложняет поддержку портала, появляются проблемы при апгрейде и попытках развития решений. Зачастую именно кастом код является причиной падений SharePoint и низкой производительности.
Казалось бы, почему просто не использовать правильную методологию? Оказывается такой методологии нет. Все что можно найти на просторах интернета – адаптация процессов разработки для SharePoint.
Как добиться успеха
В первую очередь надо фокусироваться не на поставке функционала, а на увеличении value от внедрения. Причем этот самый value надо не просто определить, а измерять. Проект считается законченным, когда достигнуты целевые показатели (KPI, связанные с value), это может случиться сразу после поставки функционала (маловероятно), а может и через год (более вероятно). План проекта должен отражать действия для достижения KPI, а не работы по созданию ПО.
Возможен и негативный вариант, когда затраты на проект растут быстрее, чем value, измеряемый в деньгах. В этом случае надо “фиксировать убытки” и закрывать проект.
Из этого следует второй принцип – делайте проекты маленькими. Чем меньше проект, тем быстрее можно достичь целевых KPI и тем меньше возможный убыток. Маленькие проекты проще запускать и проще убивать. Чем меньше проект, тем проще он поддается изменениям. Маленький проект гораздо проще аутсорсить, если своих ресурсов недостаточно. При этом можно увеличивать число проектов, запуская многие из них параллельно.
Например, вместо огромного проекта “создания корпоративного портала” на полтора года и тысячи человеко-часов, можно запустить с десяток мелких проектов, каждый со своими KPI. Буквально через месяц по каждому проекту станет ясно имеет ли смысл его продолжать.
Может казаться, что это очень сильно увеличит нагрузка на менеджера. Если вам приходилось управлять двумя-тремя проектами сразу, то десять проектов может показаться адом. Но оказывается есть зубры, которые могут управлять и 50 проектами - http://www.linkedin.com/groups/How-many-projects-can-project-37888.S.210671311. Сказывается эффект масштаба – чем больше проектов, тем проще управлять каждым в отдельности.
Последнее, но самое важное тем не менее - минимизируйте объем кастом кода, особенно при работе с server-side object model. Чем больше кода, тем дороже поддержка, тем меньше шанс на успех.
Заключение
Я понимаю, что для многих очень сложно перестроить мышление с одного большого проекта на кучу мелких, но это просто необходимо сделать. Если сложно сделать сразу, то отрезайте от большого проекта маленькие независимые кусочки и запускайте их по отдельности.
