Страницы с тегами : корпоративный портал, портал
Успех проекта SharePoint, где он?
Есть статистика, которая говорит, что более половины 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. Чем больше кода, тем дороже поддержка, тем меньше шанс на успех.
Заключение
Я понимаю, что для многих очень сложно перестроить мышление с одного большого проекта на кучу мелких, но это просто необходимо сделать. Если сложно сделать сразу, то отрезайте от большого проекта маленькие независимые кусочки и запускайте их по отдельности.
Успех проекта SharePoint, где он?
Есть статистика, которая говорит, что более половины 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. Чем больше кода, тем дороже поддержка, тем меньше шанс на успех.
Заключение
Я понимаю, что для многих очень сложно перестроить мышление с одного большого проекта на кучу мелких, но это просто необходимо сделать. Если сложно сделать сразу, то отрезайте от большого проекта маленькие независимые кусочки и запускайте их по отдельности.
Релиз SPCAF Contrib
SPCAF создавался для крупных компаний, которые работают с кучей подрядчиков, и для них очень актуальна проблема стабильности фермы в таких условиях. Проблемы, с которыми программисты сталкиваются во время разработки, в базовом наборе правил SPCop адресованы очень слабо.
Поэтому мы решили создать набор правил для SPCop, чтобы облегчить процесс разработки решений и ловить многие проблемы до того, как они проявятся во время тестирования или промышленной эксплуатации. Также создали правила, которые подсказывают best pratices при разработке решений.
Кстати мы это:
Как использовать
1. Поставить SPCop из галереи расширений Visual Studio
2. Скачать spcafcontrib.dll и положить в папку C:\Program Files (x86)\SPCOPCE\
3. Запустить анализ в Visual Studio
4. Анализируйте результаты и настраивайте правила
Заключение
Сайт SPCAF - http://www.spcaf.com/Ссылка на сайт проекта - http://spcafcontrib.codeplex.com/
Презентация - http://www.slideshare.net/gandjustas/sharepoint-code-quality
Ставьте, используйте, оставляйте feedback на сайте проекта.
Восприятие SharePoint
Пост-перевод http://veroniquepalmer.com/2014/01/16/your-sharepoint-perception/
Не правда ли, что мы склонны видеть мир через через призму нашего опыта, но не так, как на самом деле. Возьмите SharePoint например ...
- Если вы пришли из области автоматизации работы, то SharePoint всего лишь движок workflow.
- Если вы пришли из области работы с документами, то SharePoint всего лишь хранилище документов с метаданными.
- Если вы пришли из области веб-дизайна, то SharePoint обязательно надо брендить.
- Если вы пришли из области разработки, то SharePoint обязательно требует кастомизации.
- Если вы пришли из области обработки данных, то SharePoint всего лишь панели монтиторинга.
- Если вы пришли из области обучения, то SharePoint можно использовать только после обучения.
- Если вы пришли из области управления, то SharePoint работает только если есть регламенты.
- Если вы пришли из области бизнес-анализа, то SharePoint требует годы планирования.
- Если вы пришли из области социальных медиа, то SharePoint можно использовать только с версии 2013.
- Если вы пришли из области разработки расширений, то SharePoint может работать только вашим самым продаваемым продуктом.
И так можно продолжать очень долго.
Это человеческая природа, думать, что наш путь является единственным Но это не так, это лишь один из способов. Нельзя фокусироваться на одной вещи, так как SharePoint это очень большая платформа и умеет много чего еще.
Давайте посмотрим на это другим взглядом. В первую очередь взглядом потребителя. Например, если вы не используете личные узлы, это не значит что в них нет ценности для других. Расширяйте свое видение платформы и станете более более ценным специалистом.
Наша работа требует беспристрастной оценки всех возможностей, понимания всех плюсов и минусов, чтобы создавать более качественные решения для ваших клиентов.
Как обычно делают корпоративный портал на SharePoint
Недавно на facebook был опубликован (не мной) просто эпичный пост про корпоративный портал на SharePoint. Поиска по постам на facebook нет, поэтому приведу содержание здесь:
...а в конце декабря мы решили-таки натянуть новый дизайн на наш корпоративный портал. В итоге, отработав все предпоследние выхи года, получив, таким образом, поистине бесконечную 12-дневную рабочую неделю, дизайн мы-таки натянули и даже выловили все крупные и критичные баги, а не критичные оставили на новый год.
В итоге, в крайнюю пятницу старого года, взяв 30е и 31е декабря в счёт отработанных выхов, иду в бар, пью пиво и вообще всячески начинаю радоваться наступившим наконец каникулам. Но радость моя длилась ровно 2 дня, пока не закончились выходные.
В понедельник меня будит звонок руководителя, который сообщает, что портал не работает. При чем весь и полностью. До этого у нас были проблемы с главной страницей, но мы их успешно решили. А тут умерло вообще все. Ни один сайт не открывается. Исследования показали, что серваки просто не справляются с нагрузкой: очередь в IIS как при СССР за докторской колбасой, а памяти она жрет больше обычного раза в три. Кое-как продравшись в layouts, меняю мастер-страницу на дефолтную и наследую её для всех узлов. Портал моментально взлетает. Почти. Весь, кроме главной страницы. Выяснилось, что на главной странице masterpage жестко прописан в коде. Так как подрядчиков было уже не достать, оставил всё как есть и почти счастливо пошел отмечать новый год.
Сегодня танцы с бубном продолжили уже подрядчики. Код их, деньги уже уплочены, так что пусть свои косяки и исправляют. И что в итоге? А всё очень просто. В masterpage оказалась вшита веб-часть, которая подгружала курсы валют с сайта cbr.ru, но подгружала она не на серверной стороне, а на клиентской без какого-либо кеширования. В итоге, админы cbr получив с одного IP 100 000+ запросов за менее чем рабочий день, банально нас забанили. Веб-часть же начала ругаться на отсутствие аутентификации. А так как написана она была левой пяткой, то ругалась до бесконечности, не позволяя подгрузить о стальной контент страницы. Баг, который может проявиться только при опытной эксплуатации и на тестах его выявить практически нереально.
Автор поста – админ, не программист, но хорошо разбирается в SharePoint. Поэтому оставим технические детали вроде серверной\клиентской стороны для веб части (судя по симптомам загрузка курсов была именно на сервере).
Первоначально все накинулись на подрядчиков с рекомендациями писать try\catch. Но ошибка, вероятнее всего, была вызвана как раз использованием try с пустым catch (без throw) в цикле. Ошибка довольно типичная для среднестатистического разработчика SharePoint. Но самое важное в этой истории как раз то, что не написано и не касается подрядчиков вообще.
Какая необходимость вообще возникла пихать информер курсов валют на все страницы всех сайтов портала? От этого есть реальный value? Даже в финансовых организациях от силы 30% сотрудников будут получать преимущество от такого функционала, но у них, скорее всего, будет специальный софт, где будут и курсы валют и многое другое. А в среднестатистической организации курсы валют на каждой странице не нужны никому, а если вдруг кому-то понадобятся, то они быстрее зайдут на сам cbr.ru.
Коммент на тему откуда вообще появились курсы валют:
Курсы валют все равно есть и в 1С и на всяких яндексах и т.д. Но партия (руководство) сказала надо, значит надо.
Это прекрасно! Полтора года назад у меня уже был пост на тему создания решений, где тоже все свелось к мифическому “руководству”. Значит и подходы, описанные в моем посте, остаются такими же верными.
Также очевидна проблема с управлением проектом. Это надо быть очень везучим, чтобы накатывать большое обновление за несколько дней до нового года и ничего не сломалось. Но оказывается все еще интереснее:
...но проект должен был быть завершен в августе, а так как все сроки подрядчики просрали их заставили до НГ все закончить.
То есть кто-то посчитал что подрядчики, которые уже зафейлили один срок и работают в режиме аврала, сделают решение, которое не упадет на продакшене? И при этом не было никакого контроля качества? И при этом решили ставить обновление перед новым годом, а потом сразу идти в отпуска, думали что все будет хорошо?
Ну и корень всей этой ситуации:
скажу просто, что данных подрядчиков выбирали по красивой картинке, кто лучше нарисовал, тот и выиграл. Над Business-value никто особо не заморачивался. По большому счёту этот редизайн вообще никому из простых юзеров не нужен был.
Без комментариев...
Резюме
Вот так обычно делают порталы на SharePoint:
- Выбирают по красивой картинке (проблема заказчика).
- Не работают с требованиями (проблема заказчика).
- Полное отсутствие менеджмента проекта на стороне заказчика (понятно чья проблема).
- Полное отсутствие контроля качества на стороне заказчика (аналогично) .
- Подрядчики не обладают достаточной квалификацией по созданию порталов (по сути единственная проблема подрядчиков).
- У заказчика вообще нет стратегии внедрения и развития портала.
При этом все ругаются именно на подрядчиков. Хотя даже с плохими подрядчиками можно делать хорошие проекты, при нормальном менеджменте у заказчика.
Если же нет специалистов у заказчика, то обязательно нужно нанимать консультантов ДО начала проекта. Это позволит сэкономить гораздо больше денег.
Как сделать хороший корпоративный портал
Меня часто спрашивают какой должен быть хороший корпоративный портал. К сожалению универсального ответа не существует. В каждой компании своя культура, своя атмосфера и свои цели, поэтому придумать общий для всех рецепт, это как изобрести лекарство от всех болезней.
Взгляд ИТшника
Люди, работающие в ИТ, в основном имеют изобретательский слад ума. Это касается не только рядовых специалистов, но и некоторых CIO. Для них самое важное на портале – фичи. ИТшник очень быстро составит видение портала из кусков, которые предоставляет платформа, которые у видел в других порталах. При этом фичи будут максимально обобщенными, чтобы их можно было подстроить под конкретные нужды и повторно использовать для разных задач.
ИТшники очень любят автоматизировать все процессы, считая автоматизацию безусловным благом. При этом сами они пользователями этой автоматизации не являются, да и на портал ходят нечасто.
Техническое задание, написанное ИТшником, выдает множество деталей, посвященных отдельным фичам, практические полное отсутствие сведений о целях той или иной фичи и минимальное описание ролей\групп пользователей.
Взгляд дизайнера
По сравнению с ИТ специалистами это другая крайность. Порталы, придуманные дизайнерами, очень красивы. Скругленные углы, наклоненные шрифты, надкусанные фрукты. Такие картинки очень нравятся топам.
Но корпоративный портал – не сайт-визитка. Когда ИТшники пытаются впихнуть на портал функционал (все таки портал – ИТ актив), то дизайн портала начинает “плыть”. Контент, необходимый чтобы поддерживать красивость дизайна, оказывается создавать очень сложно и этим никто не занимается.
Порталы, созданные дизайнерами, всегда балансируют между красивостью и функционалом. Причем часто перекос случается в сторону красивости и это приводит к проблемам использования возможностей платформы.
В “дизайнерском” техническом задании очень мало уделяется функционала описанию, зато много визуальным элементам и макетам страниц.
Взгляд архитектора
Здесь речь пойдет об Information Architect, но на адекватного перевода на русский я не нашел.
Архитектор больше всего думает о том, чтобы портал не превратился в свалку. Тщательно прописывает типы контента и группы пользователей, информационную архитектуру и навигацию, чтобы было проще решать задачи.
Архитекторы стремятся сделать портал удобным и понятным, но без помощи дизайнеров не могут сделать его привлекательным для пользователей, а без помощи ИТ – полезным.
Так как большинство Information Architect занимаются документооборотами, то даже портал в их представлении больше похож на файлопомойку. Очень структурированную, управляемую, с хорошей навигацией, поиском, механизмами compliance, но файлопомойку.
Взгляд бизнесмена
Сочетание всех трех предыдущих взглядов необходимо для создания хорошего корпоративного портала. Но не достаточно.
Корпоративный портал является частью бизнеса компании, а цель любого бизнеса – зарабатывать деньги. Конечно напрямую зарабатывать деньги с помощью портала невозможно, зато можно получать другие преимущества – увеличение лояльности и продуктивности сотрудников, ускорение вовлечения новых сотрудников в рабочий процесс, и так далее.
Естественно лояльность и продуктивность для всех сотрудников разом увеличить не получится. Для начала нужно четко определить цели, желательно по методике SMART. Для каждой цели должны быть метрики достижения, а также целевая аудитория пользователей, релевантная данной цели. Целевая аудитория (aka сегмент пользователей) далеко не всегда будет соответствовать организационным единицам или должностям.
Далее нужно определить последовательность действий, которая приводит к достижению целей (заполнить профиль, просмотреть видеоролик, итп). После этого нужно всячески завлекать пользователей на портал и следить за метриками достижения целей. Далее можно всячески улучшать показатели.
Это очень похоже на оптимизацию сайтов. Но в случае корпоративных порталов гораздо важнее мотивировать сотрудников совершать действия и достигать целей. чем привлечь побольше релевантного трафика. Для этого как внутрипортальные механизмы мотивации - использование дизайна и контента, геймификация и подобное, так и внешняя мотивация, например плюшки для сотрудников за те или иные действия.
Естественно сразу написать план по развитию портала таким образом не выйдет. Надо постепенно ставить новые цели, развивать сервисы для отдельных аудиторий, постоянно тестировать и улучшать показатели конверсии. Начинать, в идеале, надо со стандартного функционала платформы или готовых продуктов, а потом уже заниматься кастомизацией.
Заключение
Следующий раз, когда станет вопрос о создании или развитии портала, подумайте с позиции бизнесмена. Вы сможете принести много преимуществ с минимальными ресурсами.
