Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий

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

Иначе про нее забудут, забьют и потеряют. Мне лениво лезть лишний раз за кусочком текста. Я хочу все понимать здесь и сейчас.

Документацию важно увязать с тест-планами, чтобы QA не плодил свои постановки и хотелки.

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

На заказных web-проектах и мобильных приложениях такой контур слишком затратен, тут документацией должен стать сам код, бэклог, ТЗ или описания в Swagger. Хотя время от времени сложные, интеграционные моменты приходится документировать. Особенно, если реализуется API, с которым будут работать сторонние разработчики.

Документация требует времени, ресурсов, отдельного контура управления и внимания. Ну а хорошего технического писателя – днем с огнем.

Нужна ли документация на вашем проекте? Будете ли вы ее писать по ГОСТ 19 или ГОСТ 34, или стандартам ISO? Будете ли использовать UML или BDD-подход (Behavior-driven development, дословно «разработка через поведение»), язык описания сценариев Gherkin? Вопрос, на который не надо торопиться отвечать. Делайте минимально необходимое и дополняйте по мере необходимости. Не старайтесь заранее все предусмотреть.

ЧЕЛОВЕК, КОТОРЫЙ ВСЕ ПРЕДУСМОТРЕЛ

Однажды человек решил предусмотреть на сайте ВСЕ. ВСЕ тренды, вау-эффекты, поисковые рекомендации… да мало ли. Короче, все. Ну что б потом не переделывать. Это был очень предусмотрительный человек.

И на встречу со студией он решил прийти лично. Надел костюм. Пальто. Шляпу. Взял зонтик. Подумал и на всякий случай захватил солнцезащитные очки. Перчатки. Сотовый телефон. Две запасных батарейки. Это был очень предусмотрительный человек.

Взял пару бутербродов. Бутылку коньяка. Пачку презервативов. Хлоргексидин. Перочинный ножик. Вареных яиц. Ножовку по металлу. Бумажную карту Свердловской области. Аккуратно разложил это по карманам своей жилетки. И не надо думать, что это был какой-то уникум, типа Онотолия. Просто обычный человек, который всегда все предусматривал.

Аптечку. Лыжи. Акваланг. Ласты. Бинокль.

Вышел из дому. Стоит посреди лужи. И думает: «Блин, а все ли я предусмотрел на сайте?»

3.13. Метод красной рамки

Для программистов, если они не шарлатаны, уже привычно работать итерациями. Какая-то функция на экране готова. Какая-то – нет. В новых версиях в каждый спринт, добавляется что-то новенькое. Но в целом можно уже посмотреть, как ведет себя продукт.

Чтобы не возникало вопросов, что уже готово, а что – нет, рекомендую использовать метод красной рамки. Суть в том, что прописывается специальный стиль (например. todo), выводящий тонкую красную рамку вокруг нужного нам элемента. Этот стиль присваивается тем компонентам интерфейса – кнопкам, полям, формам и т. д. – которые отражаются на экране, но еще не реализованы в коде. Таким образом наглядно видно, что в данный момент готово, а что – нет.

Этот метод работает и в заказной итеративной разработке. Заказчику не нужно будет постоянно объяснять, куда можно тыкать, а куда – нет. Если что-то не работает – мы четко разграничиваем ситуации «сломалось, баг» или «все под контролем, еще не реализовано».

Одна из первых итераций портала Северсталь. Поиск, вход, регистрация и переключение языков еще не реализованы.

Итак, плюсы:

1. Заказчик сразу видит, что готово, а что нет – не тратим время на объяснения, почему не работают некоторые поля.

2. Тестировщик понимает, какие блоки еще сырые, и не тестирует их.