devzona возможно сделаем статью по теме документации подробнее.
Если коротко, то у нас Confluence и Git в нотации AsciiDoc или Markdown. Придерживаемся внутренних стандартов, которые получились на основе практики и удобства.
Да мы смотрим в сторону автоматизации сбора документации. Сейчас уже так реализована генерация свагера для сервиса, следующий этап посмотреть в сторону разбора этого свагера на документацию (примеры запрос-ответ, вх-вых параметры сервиса).
Срочная фича в прод — это проблема менеджмента и планирования, но никак не технической команды.
Отчасти вы правы, но мы команда вместо с менеджерами и иногда срочная фича важнее в прод, чем документация до разработки, поэтому мы ищем компромисс. Но стараемся таких ситуаций не допускать.
Могут быть разные причины почему не написана или неактуальна документация:
1) команда разросталась не равномерно, сначала приходили разработчики, потом аналитики. Не было ресурсов писать аналитик сначала до разработки
2) сроки могли быть настолько сжатыми, что аналитик формулировка минимально достаточные требования, чтобы разработчик делал фичу в задаче, тестер потом тестировал, а документацию дописывал после выката в продакшен. Ведь бизнесу важнее принесенная ценность в продакшен, чем полностью описанная документация.
Да, минимальное описание всегда присутствует, но у системных аналитиков есть внутренние стандарты, количество и качество документации на фичу, чтобы по ней не было техдолга. И к сожалению, не всегда хватает ресурсов, так как кол-во аналитков в команде ограничено.
Согласна с вами, без минимальных требований разработчик не начнет зазадачу, но тут добавлю все зависит от уровня разработчика, некоторые могут взять задачу, придумать и реализовать после небольшой груминг встречи. Также в банке есть функционал, который разрабатывался без аналитики, его постепенно как раз описывают, это тоже тех.долг.
Некоторые решения знает только один разработчик, стараемся такого не допускать, то есть Лиды погружаются во все, а также есть заменяемость, но редкие случаи бывают, что без документации не разберешься, если этот один разработчик в отпуске
Разработчики проходят ревью и есть гайды, по которым это делается один из пунктов это наличие документации от разработчиков. Это технический документ, который не сможет описать никто кроме разработчика. Как правило раньше не было такой документации и многие ковырялись в коде разбирая его, но сейчас это правило внедрили и в каждую разработку закладывается время на документацию, менеджеры понимают зачем это и почему это важно.
Но большинство документации конечно пишет системный аналитик, поэтому от небольшого кол-ва разработчики не страдают
Да, хорошо выстроенный процесс-это гарантия успеха и понятной документации. То, что вы описали присутствует в нашей компании. Системный аналитик пишет бизнес-системный требования по разработанному функционалу, разработчик дополняет техническими нюансами для программистов и документ готов. Действиьельно, просить от разработчика полную документацию несколько странно, но просить часть такого как бы reade me на разработанный функционал вполне нормально, особенно если из непривычного конфлюенсе мы перевели часть документации в гит в markdown (это более привлекательный формат для разработчиков)
Но если фичу срочно нужно было в продакшен без документации, то после у каждой роли появляется своя часть техдолга документации.
Конечно каждый человек уникален и долю "своего" вносит, но благодаря процессу (что описан в статье) удалось помочь новым наставникам, добавилось прозрачности. Оптимизация здесь прошла за счёт шаблонов сбора обратной связи и презентации с итогами. Одно дело все это наставнику с нуля придумывать или просто скопировать и дополнить информацией по новичку.
Мы перешли на квартальные, как раз с годовых, так как это лучше с нашей точки зрения. Аналитик четко понимает своё развитие на квартал, из кварталов складывается год и дальше = получается стратегия (развитие по карьерной модели), но это другая тема.
Наставник не может быть всем другом, друзей не бывает много, а вот выстроить доверительное общение с помощью 1-to-1 может. При обучении наставникам дают рекомендации о чем можно поговорить на 1-to-1, какой формат выбрать и что стоит делать в различных ситуациях.
Расскажите а у вас в компании сотрудники как становятся наставниками? Был ли в вас опыт наставничества?
Onboarding новых сотрудник у нас был раньше и есть сейчас, но каждый наставник проводил его по своему. Мы оптимизировали процесс onboarding наставников для новых сотрудников.
Изобрести то, что уже изобретено не возможно, а вот посмотреть под другим углом или рассказать как у нас и чем это помогло нам, почему бы и нет.
Так что может и появятся статья про выбор квартальных целей ( как ставится цель не ради галочки и как провести "доверительный 1-to-1", а не встречу ради встречи ) :)
Личные цели на квартал выбирают сами аналитики. Если аналитик хочет стать наставником, он берёт это в личную цель и ему помогают. Также ребята могут взять в цели освоение новой технологии, прохождение курсов и др. Это не игры с hr отделом, а активность направленная на развитие аналитика как специалиста.
Руководитель может подсветить наставнику наставников, что есть потребность в обучении. Как правило наставники наставников сами выбирают обучение новых наставников в личные цели.
Жаль, что в вашей компании развитие шагает под руку с бюрократией и не помогаем вам в вашей работе.
К сожалению, я не знаю специфику работы воспитателя в детском саду, но благодаря системе наставничества наши новые сотрудники быстрее погружаются в работу в команде и в выполнение реальных задач.
До системы наставничества мы собирали обратную связь от новичков как прошел испытательный срок, так мы поняли чего им не хватает.
После внедрения процесса наставничества, обратная связь по процессу испытательного срока стала лучше.
Большинство из них имели большой опыт работы ранее и благодарили за лучшую систему наставничества среди компаний, в которых они работали.
Наставник помогает не только по организационным моментам, но также рассказывает про технические, архитектурные нюансы систем, с которыми приходится работать аналитику.
Есть первооткрыватели, которые преодолели путь наставничества самостоятельно.
За счет онбординга наставников мы стараемся увеличить кол-во наставников наставников, чтобы не возникало ситуации, что новеньких наставников не кому обучить.
Чтобы наставники наставников хотели обучать новых наставников мы добавляем такую активность в квартальные цели на развитие
Если коротко, то у нас Confluence и Git в нотации AsciiDoc или Markdown. Придерживаемся внутренних стандартов, которые получились на основе практики и удобства.
Отчасти вы правы, но мы команда вместо с менеджерами и иногда срочная фича важнее в прод, чем документация до разработки, поэтому мы ищем компромисс. Но стараемся таких ситуаций не допускать.
Могут быть разные причины почему не написана или неактуальна документация:
1) команда разросталась не равномерно, сначала приходили разработчики, потом аналитики. Не было ресурсов писать аналитик сначала до разработки
2) сроки могли быть настолько сжатыми, что аналитик формулировка минимально достаточные требования, чтобы разработчик делал фичу в задаче, тестер потом тестировал, а документацию дописывал после выката в продакшен. Ведь бизнесу важнее принесенная ценность в продакшен, чем полностью описанная документация.
Да, минимальное описание всегда присутствует, но у системных аналитиков есть внутренние стандарты, количество и качество документации на фичу, чтобы по ней не было техдолга. И к сожалению, не всегда хватает ресурсов, так как кол-во аналитков в команде ограничено.
Согласна с вами, без минимальных требований разработчик не начнет зазадачу, но тут добавлю все зависит от уровня разработчика, некоторые могут взять задачу, придумать и реализовать после небольшой груминг встречи. Также в банке есть функционал, который разрабатывался без аналитики, его постепенно как раз описывают, это тоже тех.долг.
Некоторые решения знает только один разработчик, стараемся такого не допускать, то есть Лиды погружаются во все, а также есть заменяемость, но редкие случаи бывают, что без документации не разберешься, если этот один разработчик в отпуске
Разработчики проходят ревью и есть гайды, по которым это делается один из пунктов это наличие документации от разработчиков. Это технический документ, который не сможет описать никто кроме разработчика. Как правило раньше не было такой документации и многие ковырялись в коде разбирая его, но сейчас это правило внедрили и в каждую разработку закладывается время на документацию, менеджеры понимают зачем это и почему это важно.
Но большинство документации конечно пишет системный аналитик, поэтому от небольшого кол-ва разработчики не страдают
Да, хорошо выстроенный процесс-это гарантия успеха и понятной документации. То, что вы описали присутствует в нашей компании. Системный аналитик пишет бизнес-системный требования по разработанному функционалу, разработчик дополняет техническими нюансами для программистов и документ готов. Действиьельно, просить от разработчика полную документацию несколько странно, но просить часть такого как бы reade me на разработанный функционал вполне нормально, особенно если из непривычного конфлюенсе мы перевели часть документации в гит в markdown (это более привлекательный формат для разработчиков)
Но если фичу срочно нужно было в продакшен без документации, то после у каждой роли появляется своя часть техдолга документации.
Конечно каждый человек уникален и долю "своего" вносит, но благодаря процессу (что описан в статье) удалось помочь новым наставникам, добавилось прозрачности. Оптимизация здесь прошла за счёт шаблонов сбора обратной связи и презентации с итогами. Одно дело все это наставнику с нуля придумывать или просто скопировать и дополнить информацией по новичку.
Мы перешли на квартальные, как раз с годовых, так как это лучше с нашей точки зрения. Аналитик четко понимает своё развитие на квартал, из кварталов складывается год и дальше = получается стратегия (развитие по карьерной модели), но это другая тема.
Наставник не может быть всем другом, друзей не бывает много, а вот выстроить доверительное общение с помощью 1-to-1 может. При обучении наставникам дают рекомендации о чем можно поговорить на 1-to-1, какой формат выбрать и что стоит делать в различных ситуациях.
Расскажите а у вас в компании сотрудники как становятся наставниками? Был ли в вас опыт наставничества?
А на каком языке и с какими фактами защищать архитектуру перед безопасностью компании?
Как правило тут то все новое и технологичное может не пройти
Onboarding новых сотрудник у нас был раньше и есть сейчас, но каждый наставник проводил его по своему. Мы оптимизировали процесс onboarding наставников для новых сотрудников.
Изобрести то, что уже изобретено не возможно, а вот посмотреть под другим углом или рассказать как у нас и чем это помогло нам, почему бы и нет.
Так что может и появятся статья про выбор квартальных целей ( как ставится цель не ради галочки и как провести "доверительный 1-to-1", а не встречу ради встречи ) :)
Личные цели на квартал выбирают сами аналитики. Если аналитик хочет стать наставником, он берёт это в личную цель и ему помогают. Также ребята могут взять в цели освоение новой технологии, прохождение курсов и др. Это не игры с hr отделом, а активность направленная на развитие аналитика как специалиста.
Руководитель может подсветить наставнику наставников, что есть потребность в обучении. Как правило наставники наставников сами выбирают обучение новых наставников в личные цели.
Жаль, что в вашей компании развитие шагает под руку с бюрократией и не помогаем вам в вашей работе.
До системы наставничества мы собирали обратную связь от новичков как прошел испытательный срок, так мы поняли чего им не хватает.
После внедрения процесса наставничества, обратная связь по процессу испытательного срока стала лучше.
Большинство из них имели большой опыт работы ранее и благодарили за лучшую систему наставничества среди компаний, в которых они работали.
Наставник помогает не только по организационным моментам, но также рассказывает про технические, архитектурные нюансы систем, с которыми приходится работать аналитику.
За счет онбординга наставников мы стараемся увеличить кол-во наставников наставников, чтобы не возникало ситуации, что новеньких наставников не кому обучить.
Чтобы наставники наставников хотели обучать новых наставников мы добавляем такую активность в квартальные цели на развитие