@seva1

Технический писатель или аналитик?

Привет

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

Детально, проблема состоит в следующем
1) Провели совещания, договорились об определенном процессе как например нужно вести работу по Development`у(Работа с тикетами, комитами, бренчами, выпуск release notes итд) - но описать этот процесс, понятные языком, в виде инструкции-регламента никто не может, ну или кажется, что описали хорошо - но новому человеку это будет не понятно.
2) Вроде бы на весь функционал, что делаем и ставим Тикеты, и описываем продуктовые требования, тест кейсы, user guide - но опять же, чувствуется что нет единой структуры документации.

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

Главная задача - чтобы продукт не был черным ящиком, который зависит жестко от людей в команде(То есть вход нового человека - это погружение на долгие месяцы в разбирательство, а как же все работаем)

Работаем на продуктах Atlassian(Jira, Confluence, BitBucket, Fish Eну + Crucible, Bamboo).

Вопрос - Кто должен/может решить данную "боль" - это больше задача для технического писателя, либо бизнес аналитика?

Спасибо
  • Вопрос задан
  • 2197 просмотров
Пригласить эксперта
Ответы на вопрос 4
DmitriyEntelis
@DmitriyEntelis
Думаю за деньги

Договорились об определенном процессе как например нужно вести работу по Development`у(Работа с тикетами, комитами, бренчами, выпуск release notes итд)
...
Вроде бы на весь функционал, что делаем и ставим Тикеты, и описываем продуктовые требования, тест кейсы, user guide - но опять же, чувствуется что нет единой структуры документации.
...
Вопрос - Кто должен/может решить данную "боль"

Задачу правильной организации процесса разработки должен решать технический руководитель проекта.

Главная задача - чтобы продукт не был черным ящиком, который зависит жестко от людей в команде(То есть вход нового человека - это погружение на долгие месяцы в разбирательство, а как же все работаем)

Наличие понятной формализированной документации это бесспорно плюс, но по моему личному опыту вход нового человека в сложный монолитный проект все равно требует времени, т.к документация имеет тенденцию бесконтрольно разрастаться.
Решение во многом архитектурное, дробить проект на простые микросервисы, каждый из которых имеет независимую документацию, etc.
Ответ написан
Комментировать
По-моему, вопрос не в техническом писателе или аналитике, а в недостаточно эффективном управлении проектом.
...но нет этого связующего звена в компании пока...

Профессиональный менеджер и является тем самым "звеном", которое не только проведет грамотное совещание с реальным результатом и системно организует работу с документацией, но и сможет поставить базовые управленческие процессы, как то: планирование, координацию, контроль и т.д. Вот только хорошего менеджера придется поискать. Прочие решения, в том числе и технические или программно-сервисные не только не решат указанные проблемы, но и усугубят ситуацию. Вероятно проект достиг той точки развития, когда нужно налаживать управление.
Ответ написан
Комментировать
alexey-m-ukolov
@alexey-m-ukolov Куратор тега Веб-разработка
Технический писатель может не разбираться в предметной области достаточно глубоко, а аналитик может не уметь писать на человеческом языке.
Следовательно, вам нужен и тот и другой. Но, раз в команде есть люди, которые понимают, как и что работает, можно попробовать обойтись без аналитика.
Ответ написан
Комментировать
@murlogen
1. Решать все головные боли должно руководство.

Или точнее - заинтересованный в проекте человек с достаточными полномочиями должен раздавать всем пинка, как только что-то начинает буксовать.

Если такого человека нет (он не достаточно имеет полномочий или заинтересованности) - закрывайте проект.

2. Достаточно сделать boilerplate (шаблон или несколько) - который будут все использовать. В приказном порядке.
Читать все эти длинные регламенты и пр. - никто не будет.
Описания как работать - должны быть 3-4 экрана высотой, не более.

Не мешайте людям работать.
Помогите им - сделайте ваш корпоративный boilerplate

Человек просто берет его.
И модернизирует под свой участок проекта.

Заведите удобный wiki-подобный комментарий к boilerplate.
Документация появится сама.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы