Привет
Идет процесс разработки нового проекта и вижу, что мы буксуем в области написания регламентов, инструкций и описания процессов и самого продукта.
Детально, проблема состоит в следующем
1) Провели совещания, договорились об определенном процессе как например нужно вести работу по Development`у(Работа с тикетами, комитами, бренчами, выпуск release notes итд) - но описать этот процесс, понятные языком, в виде инструкции-регламента никто не может, ну или кажется, что описали хорошо - но новому человеку это будет не понятно.
2) Вроде бы на весь функционал, что делаем и ставим Тикеты, и описываем продуктовые требования, тест кейсы, user guide - но опять же, чувствуется что нет единой структуры документации.
Есть люди, с которых можно снять информацию, а как работает, а что, а почему - но нет этого связующего звена в компании пока.
Главная задача - чтобы продукт не был черным ящиком, который зависит жестко от людей в команде(То есть вход нового человека - это погружение на долгие месяцы в разбирательство, а как же все работаем)
Работаем на продуктах Atlassian(Jira, Confluence, BitBucket, Fish Eну + Crucible, Bamboo).
Вопрос - Кто должен/может решить данную "боль" - это больше задача для технического писателя, либо бизнес аналитика?
Спасибо
Договорились об определенном процессе как например нужно вести работу по Development`у(Работа с тикетами, комитами, бренчами, выпуск release notes итд)
...
Вроде бы на весь функционал, что делаем и ставим Тикеты, и описываем продуктовые требования, тест кейсы, user guide - но опять же, чувствуется что нет единой структуры документации.
...
Вопрос - Кто должен/может решить данную "боль"
Задачу правильной организации процесса разработки должен решать технический руководитель проекта.
Главная задача - чтобы продукт не был черным ящиком, который зависит жестко от людей в команде(То есть вход нового человека - это погружение на долгие месяцы в разбирательство, а как же все работаем)
Наличие понятной формализированной документации это бесспорно плюс, но по моему личному опыту вход нового человека в сложный монолитный проект все равно требует времени, т.к документация имеет тенденцию бесконтрольно разрастаться.
Решение во многом архитектурное, дробить проект на простые микросервисы, каждый из которых имеет независимую документацию, etc.
По-моему, вопрос не в техническом писателе или аналитике, а в недостаточно эффективном управлении проектом.
...но нет этого связующего звена в компании пока...
Профессиональный менеджер и является тем самым "звеном", которое не только проведет грамотное совещание с реальным результатом и системно организует работу с документацией, но и сможет поставить базовые управленческие процессы, как то: планирование, координацию, контроль и т.д. Вот только хорошего менеджера придется поискать. Прочие решения, в том числе и технические или программно-сервисные не только не решат указанные проблемы, но и усугубят ситуацию. Вероятно проект достиг той точки развития, когда нужно налаживать управление.
Алексей Уколов
@alexey-m-ukolov Куратор тега Веб-разработка
Технический писатель может не разбираться в предметной области достаточно глубоко, а аналитик может не уметь писать на человеческом языке.
Следовательно, вам нужен и тот и другой. Но, раз в команде есть люди, которые понимают, как и что работает, можно попробовать обойтись без аналитика.
Или точнее - заинтересованный в проекте человек с достаточными полномочиями должен раздавать всем пинка, как только что-то начинает буксовать.
Если такого человека нет (он не достаточно имеет полномочий или заинтересованности) - закрывайте проект.
2. Достаточно сделать boilerplate (шаблон или несколько) - который будут все использовать. В приказном порядке.
Читать все эти длинные регламенты и пр. - никто не будет.
Описания как работать - должны быть 3-4 экрана высотой, не более.
Не мешайте людям работать.
Помогите им - сделайте ваш корпоративный boilerplate
Человек просто берет его.
И модернизирует под свой участок проекта.
Заведите удобный wiki-подобный комментарий к boilerplate.
Документация появится сама.
Средний