Техническое собеседование на руководителя проектов в Ригла

Давно не было реальных собеседований. 7 марта собеседовался в сеть аптек «Ригла» на руководителя проектов с внутренним заказчиком. В целом, собеседование прошёл удачно, на все вопросы ответил, не сошлись, относительно графика. У них рабочий день зачем-то начинается в 9:15 по МСК, а у меня -1 и это будет безумно рано. Договориться на более позднее начало рабочего дня не удалось — руководитель считает, что правила едины для всех.

Собеседование было с руководителем группы развития департамента информационных технологий Ригла.

Ну что же, полетели:

Перечислите этапы айти-проекта от начала до конца

• Инициация.
• Планирование.
• Исполнение.
• Мониторинг и контроль.
• Завершение и передача на поддержку.

В случае работы по гибким методологиям, подход другой. У нас есть бэклог продукта, мы из него формируем бэклог спринта, идём итерациями, в конце каждой итерации выпускаем инкремент.

В каком случае имеет смысл работать по ватерфолу, когда же нужны гибкие методологии?

Если проект не очень большой (в пределах года, многолетние проекты лучше делать по гибким или гибридным методологиям), у него есть более-менее фиксированные требования, которые не должны меняться, а также устойчивая среда, есть смысл делать по ватерфолу с разбиением его на итерации.

Если мы говорим о высокой степени неопределённости, изменчивой среде и вообще, продуктовом подходе, лучше подойдут гибкие методологии.

Что происходит на этапе инициации проекта?

Составляем паспорт или устав проекта. Формируем и фиксируем тройственное ограничение. Это будут формальные критерии успешности проекта.

Определяем, кто спонсор, кто менеджер. Ключевые люди проекта.

Набираем команду, проводим кикофф-встречу.

Подписываем основные юридические документы. Как правило, это рамочный договор, потом к нему будут допсоглашения.

Что такое критерии успешности проекта, как определить, что проект успешен?

Когда я был моложе и менее опытен, говорил, что по попаданию в треугольник ограничений. Став опытнее, я стал говорить, что основной критерий успешности — удовлетворённость заказчиков или стейкхолдеров.

Удовлетворённость внешних заказчиков определяется по готовности работать с нами дальше.

Удовлетворённость внутренних стейкхолдеров определяется по тому, используется ли разработанный продукт в реальной практике. Померить, как правило, можно экономическим эффектом. Можно вешать на процессы метрики и измерять, как проект на них повлиял.

Что происходит на этапе планирования?

Прорабатываем детальное ТЗ. Собираем с заказчика требования, анализируем их, формализуем и фиксируем. Потом согласуем. Иногда в процессе формирования требований, проект может разрастись.

Некоторые люди считают, что если изменилось тройственное ограничение, проект надо закрыть и начать новый. Я так не считаю, я считаю, что его можно переписать.

Если в середине проекта влетает требование, без которого дальнейший проект бессмыслен, но которое изменяет одно или несколько значений тройственного ограничения, что мы делаем?

Управление изменениями.

Опытная эксплуатация, промышленная эксплуатация, в чём разница?

При опытной эксплуатации у нас ограниченное количество пользователей. Выделяется фокус-группа, которая будет продукт гонять и давать ОС. При передаче в опытную эксплуатацию мы даём первый «транш» документации.

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

Что такое пилотный проект и чем он отличается от MVP?

В рамках пилотирования мы проверяем ключевые гипотезы и пытаемся понять, есть ли смысл вписываться в большой и страшный проект.

Этапа MVP в пиэмбоке нет. На пилотном проекте мы делаем более-менее завершённую функциональность, работающий продукт, пусть и не покрывающий 100 % требований заказчика. На MVP это может быть склеенный на коленке прототип, проверяющий основную гипотезу — на гуглотаблицах-формах, телеграм-ботах, тильде, чём угодно.

Пилотный проект — это живое мероприятие с участием небольшой группы реальных пользователей, получающих новую услугу. Он используется, когда есть уверенность в эффективном решении и нужно сгладить недостатки и понять, как оно работает в реальности. Это помогает выявить и устранить любые проблемы перед распространением на более широкую аудиторию. 13

MVP (минимально жизнеспособный продукт) — метод изучения потенциального решения при использовании минимальных ресурсов. Он тестирует только основную суть идеи с реальными пользователями. Это позволяет на ранней стадии выяснить, есть ли реальная потребность в решении, что работает, а что нет, и внести соответствующие коррективы.

Яндекс.Нейро

Как выберете подрядчика и продукт для поставки ПО?

В B2B важна репутация. Я бы отслеживал инфу от людей, которые с этим подрядчиком уже работали.

Пробив по юридическим базам в сторону судебных процессов.

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

Чтобы сравнивать продукты разных вендоров с одинаковыми функциями, можно оценивать такие критерии:

• Отзывчивость техподдержки.
• Скорость работы софта, способность работать под нагрузкой.
• Юзабилити. Насколько он дружелюбен к пользователю. Насколько современны интерфейсы.
• Частота обновления продукта.

Какое ваше мнение о правиле трёх кликов?

Не придерживаюсь, считаю, что кликов может быть сколько угодно, пока каждый клик очевиден. Структура данных или функций может быть такой сложной, что в три клика сделать все функции доступными может быть невозможно.

При передаче продукта на поддержку, что должно быть?

Само ПО и инструменты логирования ошибок с отправкой логов на сервера разработчиков.

Документация. Техподдержка должна понимать, как продукт работает. Её есть несколько видов:

• Руководство пользователя-администратора.
• Руководство по развёртыванию.
• Требования и пояснительные записки (при передаче на поддержку менее критичны).

В дополнение к инструкции пользователя могут быть дополнительные инструкции по работе со специфическими бизнес-процессами. Хорошо работают скринкасты.

Как внедрить веб-продукт на 15 000 человек?

Используя существующую оргструктуру, существующих менеджеров и администраторов.