Спасибо, тоже нашёл. Получается у них базовый курс + персональный преподаватель-куратор.
Пока не нашёл информацию, выдаётся ли сертификат об обучении.

Коллеги, добрый вечер!  @Roman_Bug, назвал мою статью https://habr.com/ru/post/480050/ "интересной". Хотя, на мой взгляд, она достаточно провокационна в этом сообществе 😊. Тем интереснее было бы услышать ваше мнение

Отсутствие внятных ответов на вопросы: «зачем/почему мы это реализовали именно так» или «всё ли мы сделали, что хотел от нас заказчик» — вызывали у нас живое беспокойство.

И вот в какой-то момент нам показалось, что концепция «документация — это код»

Не оч понял как эти две вещи связаны

какая разница где и как хранятся доки, если вы делаете непонятно что?

до конца прочитали?

не, бросил на моменте когда вам показалось, мысленно проговорив, что "когда кажется креститься надо" и закрыл

Это мнение. Спасибо )

Хм, мне кажется, documentation as code - это относиться к документации как к коду (в смысле VCS), а не то, что документация и код лежат в одном месте и развиваются совместно

Документация как код и код как код под контролем VCS.  Но это никак не гарантирует, что они будут развиваться совместно. И в этом я вижу проблему

Это общая проблема документации, а не проблема именно подхода docs as code

Абсолютно согласен. Об этом статья

В таком случае, заголовок несколько обманчив. Тем не менее, о собственно документации, о результате творческого процесса техписателя, в тексте я особо упоминаний не нашёл, разве что косвенно.

Смотрите, если говорить о предложенной методике ведения разработки "BDDSM", то творческая часть процесса ложится на плечи бизнес-аналитика, а выходная документация уже будет зависеть от того, насколько качественно были описаны требования в feature-файлах. В этом как раз и вся провокативность, поскольку при таком подходе технический писатель как бы и не нужен, поскольку его роль на себя перебирает бизнес-аналитик. Либо технический писатель будет оттачивать своё мастерство, уже постфактум - но в рамках свободных блоков feature-файлов, в которых можно использовать Markdown (это синтаксис позволяет).

"технический писатель как бы и не нужен" — вы не очень удачную группу выбрали для таких заявлений, как мне кажется :)

я уже пару сообщений написал и стёр, Ник, конечно, терпеливый, но не буду его терпение испытывать

Извините, никого не хочу обидеть. Мне действительно интересно ваше мнение. Если у вас в компаниях workflow построен таким образом, что проблемы отрывы изначальных требований от конечного результат нет, то хотелось бы узнать, как у вас это работает.
Мы провели эксперимент на людях, которые так как описано в статье никогда не работали, для них это была боль. Но результат мне понравился, о чём я и написал.

Провокации бывают полезны. Завтра почитаю, выскажусь.

Спасибо

Согласен. Лежать они могут и в разных местах. Смысл именно в обращении как с кодом: версионирование, ревью, тесты, линтеры, CI, модульность, переиспользование, автогенерация, связи, много артефактов из одного источника (это то что называют концепцией единого источника), разделение содержимого и представления, версионирование исходника но не артефактов...