Риски, связанные с работой разработчиков. Автоматизация тестирования

Риски, связанные с работой разработчиков. Автоматизация тестирования

Программисты – очень милые люди, представляющие большую потенциальную опасность для портала. Риски, связанные с их работой, можно разделить на две группы: технические и организационные.

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

В случае задержки можно:

? наказать лишением бонуса или иным способом (как материально, так и словами). Наказание применимо только в том случае, если причина невыполнения плана заключается в лени или явном нежелании заниматься выполнением конкретной задачи. Во всех остальных случаях (слишком сложное или плохо составленное ТЗ, недостаточная квалификация разработчика, слишком амбициозный план, недостаток ресурсов) техническому директору следует наказать себя;

? добавить ресурсов – ввести в проект новых специалистов. Очень спорное решение – практика показывает, что введение в рабочую группу новых разработчиков может как ускорить завершение проекта, так и отсрочить его. Последнее связано с тем, что на введение новых разработчиков в курс дела необходимо время, а кроме того, при увеличении количества разработчиков в группе растут временные затраты на их взаимодействие. Важно также понимать, что девять женщин не могут родить одного ребенка за один месяц;

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

Очевидно, что перечисленные меры могут использоваться как по отдельности, так и в комплексе. Целесообразность тех или иных решений в конкретном случае определяется индивидуально. Подробнее об управлении разработчиками ПО читайте в специализированной литературе.

Технические риски гораздо более опасны, нежели организационные. О задержке мы узнаем не позже дедлайна, а вот о том, что у 50 000 страниц перестали отображаться Title, можно узнать из аудита. При этом стопроцентно защитить портал от подобных ошибок практически невозможно, а в рамках большого и динамично развивающегося проекта они будут возникать постоянно, и это является серьезной проблемой.

Решение проблемы – в создании автоматизированной системы мониторинга. Она позволит своевременно узнавать о возникновении подобных неполадок и устранять их до того, как они причинят большой ущерб.

Что должна анализировать система?

? Изменения robots.txt.

? Наличие и значительные изменения карты сайта.

? Коды ответов сервера по разным разделам и поддоменам.

? Скорость загрузки страниц разных разделов и поддоменов.

? Содержимое Title и Description на страницах разных разделов и поддоменов (важна ротация страниц).

? Правильную обработку важных форм.

? Корректность важных ссылок.

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