Управленческие риски

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

К управленческим рискам можно отнести и организацию взаимодействия с заказчиком, организацию процесса производства в самой компании.

Детально управленческие риски рассмотрены в уроке Эффективная работа команды.

  Риски проектирования

Забота о рисках проектирования лежит целиком на менеджере проекта. Это ещё один аргумент в пользу того, что им должен быть менеджер-технолог. Для уменьшения вероятности провала проекта необходимо составить "план управления рисками", который необходимо обсудить с клиентом. Для более точной оценки рисков необходимо провести тестирование на прототипе. Смоделируйте нагрузку и проверьте свои решения.

Типичные ошибки стратегии и тактики:

• Отсутствует видение системы: "Давайте начнем делать систему, а программисты придумают как это реализовать".
• При рассмотрении ТЗ менеджер проекта соглашается на любые модификации: ядра, админки, визредактора и т.п., в угоду бизнес-целям веб-студии.
• Менеджер проекта не уделяет проектированию и созданию прототипа должного значения.
• Вопрос производительности «закрывается» железом.
• Заказчик отказывается мыслить логически.

Чтобы избежать этих ошибок:

• При проектировании нужно разделить запрашиваемый заказчиком функционал на стандартный и нестандартный для используемой платформы.
• Проектировщик в деталях должен понимать, как реализовать стандартный функционал.
• Составьте логическую модель данных, глоссарий, кейсы использования. Растолкуйте их Клиенту.
• Сделайте Клиента участником проектной команды.
• Сделайте прототипы для снятия технических рисков (сложные технологии, нагрузка).
• Сделайте прототипы интерфейсов.
• Менеджер проекта должен вызубрить онлайн курсы по Bitrix Framework, если проект разрабатывается на Bitrix Framework.

  Риски разработки

Риски разработки зависят от подготовки программистов, знания ими продукта, а также от стратегии и тактики разработки, выбранной менеджером проекта.

Типичные ошибки стратегии и тактики (убывание по важности):

• Не определена программная структура проекта.
• Отсутствует, либо реально не работает система контроля версий.
• Бесконтрольное программирование на ООП. Создаётся сложная иерархия для решения проблемы, которую можно решить одним скриптом. Нерациональное использование трудовых ресурсов для решения задач.
• Не используются инструменты отладки кода.
• Не регулируются права доступа на тестовых, боевых, девелоперских серверах: все сотрудники работают от root.
• "Секретные" объекты: агенты, обработчики, созданные самими разработчиками. Эти объекты могут быть недокументированы, располагаться где и как попало, что затрудняет дальнейший их поиск и отладку.
• Отправка транзакций на e-mail разработчику. Отключение этой нужной в ходе разработки функции может быть просто забыто.
• Отсутствие комментариев в коде.
• Лог-файлы размещаются в корне сайта.

Типичные ошибки при использовании собственно Bitrix Framework:

• Модификация ядра
• Прямые запросы в БД.
• Код пишется либо вне компонентов, либо в шаблонах компонентов. Объяснение: "так удобнее", вопреки идеологии Bitrix Framework.
• Настройки собственных, либо кастомизированных компонентов работают частично. После сдачи проекта им будет управлять администратор, и ему некогда, да и не должен он разбираться в собственно коде компонента.
• Огромные файлы кэша - не учтены все особенности кеширования. Встречается кеширование всего, что попало "под руку".
• Огромный init.php.
• Не оптимальное использование API Bitrix Framework, как правило, вызванное плохим знанием разработчиком API системы.
• Беспорядочный /bitrix/php_interface/dbconn.php.
• Обработчики событий переопределены везде, где можно, без комментариев зачем.
• Эксплуатационные параметры могут задаваться константами где угодно, на страницах, в компонентах, в классах модулей.

  Информационная безопасность

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

API Bitrix Framework – защищено, написание кода в обход него всегда чревато если не текущими ошибками, то потенциальными проблемами, если вдруг обнаружится какая-то уязвимость.

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

Не забывайте перед сдачей проекта удалить тестовых пользователей, тестовые группы, тестовые файлы, лишние резервные копии. И обязательно использовать Монитор качества

  Эксплуатация

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

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

Видео

Подводные камни разработки - чего делать нельзя

Программная архитектура веб-систем на Битриксе: от простого сайта до веб-кластера

Особенности проектирования под Битрикс