понедельник, 28 марта 2011 г.

"Обязательно все документируйте, хоть это и бессмысленно" (С)

Давно собиралась написать большой и красивый пост про документацию в проекте (а мне тут есть о чем написать!), а тут еще и наткнулась на "Обязательно все документируйте" vs "документацию писать бессмысленно" на Хабре. И поняла, что пора. )))

Рассмотрим пример. Изначально на проекте документации не велось вовсе.
В принципе, зачем документация на проект в три программиста? Потом проект взрослел, крепчал и появилась необходимость в спецификациях. Писать их начали программисты.
Проект рос и рос. Появились новые люди, в том числе - отдел тестирования. Спецификации начали подвергаться тестированию вместе с непосредственно функционалом. 
Проект увеличивался. Команда сменила методологию разработки и одновременно с этим изменился подход к написанию документации.
Теперь программисты начали писать не только документацию на имплементацию, но и документировать требования, бизнес-процессы и интерфейсы. Тестировщики пишут тест-кейсы. Копирайтер пишет статьи и факи для пользователей.
Анализ фичи и последующее написание документации занимает более 30% положенного времени. Программисты хотят кодить и совсем не хотят писать документацию по проекту.

Я вижу здесь три варианта развития событий.
Первый: таки мотивировать чем-то программистов (скорее всего, тут сработает только метод кнута - вопрос только в его эффективности), чтобы они и в дальнейшем писали документацию. Рассказать им про всякие принципы "лягушек", которых нужно есть с утра, и успокоиться.
Второй: спихнуть написание документации на Project Owner, который непосредственно общается с заказчиком и точно знает, что тот хочет. Основной затык здесь: стоимость времени РО, а также наличие этого самого времени, которого даже в настоящий момент едва хватает на проверку уже написанной документации.
Третий (и, наверное, не последний): поручить написание документации тем, кому это реально в кайф. Я думаю, что такие люди есть, но тщательно шифруются. Затык здесь: проектов несколько, а человек может быть один. Вникать в несколько проектов сразу ему может быть затруднительно.

Основные дискуссии велись вокруг первого и третьего вариантов.
Интересно, а какие еще варианты развития событий могут быть?

9 комментариев:

  1. Насчет третьего варианта...
    Для этого существуют бизнес-аналитики, или аналитики, которые способны проанализировать требования Заказчика, спроектировать структуру проекта, базу данных, написать Техническое задание, Функциональные требования, при необходимости, Постановку Задачи. ))

    ОтветитьУдалить
  2. Согласна полностью с тем, что существуют такие люди, как бизнес-аналитики, способные многое анализировать и писать.
    Но существует такое понятие как "кроссфункциональная команда", в которое некоторые руководители вкладывают не изначальный смысл, а "команда, где каждый может выполнять работу каждого". Т.е. программист может тестировать, тестировщик - программировать и т.д. И тут уже понятно, что никаких бизнес-аналитиков не нужно - команда справится и без них ))))

    ОтветитьУдалить
  3. Программисты должны программировать, писать комментарии и спеки того, что они собираются (или уже) накодить ) ТТ, ТЗ - отдельная сфера, требующая специальных навыков. Но это , конечно, все в идеале..

    ОтветитьУдалить
  4. Полностью кросс-функциональная команда - это миф :) Руководителю уже пробовали это объяснить?)
    Бизнес-аналитик на то и "бизнес", чтобы заботиться о том, чтобы продукт решал бизнес-задачи заказчика, при чем тут разработчики и тестировщики?

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

    ОтветитьУдалить
  5. 2will:
    Согласна с Вами на все 100% )))

    2Роман:
    Мифичность кроссфункциональности пока "жестоко" объяснять не пробовали. Я сейчас пытаюсь закидывать пробные камни, смотрю на реакцию. ))) Думаю, уже то, что взяли пару месяцев назад технического писателя, уже прогресс )))
    За обмен опытом спасибо! ))

    ОтветитьУдалить
  6. Просто интересно, каким способом или методом тестирования можно заманить девелопера в тестировщики? :)
    Кроссфункциональная комманда это конечно хорошо ровно так как и к примеру акушер-бетонщик, извиняюсь. Но ожидать от хорошего акушера прорыва в бетонизации пространства думаю не стоит как и наоборот.
    ИМХО

    ОтветитьУдалить
  7. Viktor, акушер-бетонщик - это просто в мемориз!! ))))
    А "заманить" довольно просто: "У нас релиз через неделю, а тестировщики не успевают!" - говорится от лица гендиректора, обмахивающегося зарплатной ведомостью.
    Про эффективность тут речи не идет.
    Но, согласитесь, "и швец, и жнец, и на дуде игрец" - мечта каждого менеджера. И как тут добровольно отказаться от идеи кроссфункциональной команды?

    ОтветитьУдалить
  8. Мечты, мечты...что б делал бе з них человек разумный, откуда б черпал вдохновение... :)
    Согласен, когда горят дьюдэйты деваться некуда.
    У нас и сапорт тестирует. Но как по мне не по феншую это все. Каждый должен заниматься своим делом. И чем уже специальность человека, чем уже круг его задач тем более качественно он может делать свою работу. Ну это достаточное условие. Для выполнения необходимого еще надо желание делать это.

    ОтветитьУдалить
  9. Согласна. )) У меня в таких случаях острое желание перетестировать...

    ОтветитьУдалить