Управление знаниями: какие документы нужны и что в них фиксировать (TeamLeadConf-2018) — различия между версиями
м |
м (Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}) |
||
(не показаны 3 промежуточные версии этого же участника) | |||
Строка 1: | Строка 1: | ||
+ | {{RightNote|[[:Категория:Архитектура|Еще про архитектуру]]}} | ||
Выступление на [http://teamleadconf.ru/2018/ TeamLead Conf] '''8-9.02.2018''' в Москве | Выступление на [http://teamleadconf.ru/2018/ TeamLead Conf] '''8-9.02.2018''' в Москве | ||
[http://teamleadconf.ru/2018/abstracts/3144 Доклад на сайте конференции] | [http://teamleadconf.ru/2018/abstracts/3144 Доклад на сайте конференции] | ||
+ | [https://habr.com/ru/company/oleg-bunin/blog/438820/ '''Расшифровка доклада в статье на habr'''] | ||
[https://www.facebook.com/mtsepkov/posts/1654908334566114 Пост на FB] | [https://www.facebook.com/mtsepkov/posts/1654908334566114 Пост на FB] | ||
Строка 12: | Строка 14: | ||
Управление знаниями имеет еще один аспект, который находится за рамками проекта - обмен профессиональными знаниями между специалистами разных проектов. Здесь я рассчитываю поделиться практиками и кейсами, знакомыми мне из участия в сообществе Knowledge Management Russia, в конференциях которого я принимаю участие с 2010 года (отзывы на моем сайте http://mtsepkov.org/KM). | Управление знаниями имеет еще один аспект, который находится за рамками проекта - обмен профессиональными знаниями между специалистами разных проектов. Здесь я рассчитываю поделиться практиками и кейсами, знакомыми мне из участия в сообществе Knowledge Management Russia, в конференциях которого я принимаю участие с 2010 года (отзывы на моем сайте http://mtsepkov.org/KM). | ||
+ | |||
+ | В целом доклад развивает мое выступление '''[[Agile и управление знаниями в ИТ-проектах (KM Russia-2016)|Agile и управление знаниями в ИТ-проектах]]''' на конференции '''[http://kmrussia.ru KM Russia]''' 15-16.12.2016. | ||
=Видео= | =Видео= |
Текущая версия на 18:21, 7 декабря 2023
Выступление на TeamLead Conf 8-9.02.2018 в Москве Доклад на сайте конференции Расшифровка доклада в статье на habr Пост на FB
Набор документов, которые должны сопровождать проект - одна из известных холиварных тем. Одни выступают за стройные системы документов из стандартов, другие - за минимализм, вплоть до лозунга "код - вот лучшая документация", и у всех есть множество историй, подтверждающих точку зрения. Как и большинство холиваров, нет смысла обсуждать этот вопрос в общем виде, его надо решать практически в контексте конкретного проекта или продукта. При этом опираться следует не столько на назначение и сложность самого продукта, сколько на процесс его разработки и эксплуатации, потому что любой документ - средство коммуникации и полезен лишь настолько, насколько ее поддерживает. Отметим, что большинство описанных в учебниках систем документации были разработаны для водопадной разработки в условиях слабого изменения требований. А нынешний процесс разработки носит совершенно другой характер, и ему нужны другие артефакты.
Маленький пример: в формате user story "как <роль> я хочу <сделать что-то> для того чтобы <достичь целей>" часть с целью появилась не сразу. Она нужна, чтобы разработчик мог поставить себя на место пользователя, если в процессе реализации надо выбрать между несколькими альтернативами. Казалось бы, можно спросить, однако прерывание разработки – дорого, и разработчики часто додумывают за пользователя, и часто ошибались. Указание цели пользователя позволяет уменьшить число неверных решений. Кстати, сам формат появился при переходе к итеративной разработке как средство обеспечить инкрементальную поставку ценного продукта.
Долговременная документация проекта тоже служит коммуникации: ты-нынешний с тобой-будущим, которому надо быстро вспомнить контекст; ты и пользователи системы и другие.
Подход к проектированию документации аналогичен проектированию интерфейсов: описываешь кейсы коммуникаций, определяешь, какими документами и артефактами это обеспечивается, понимая, что каждый документ имеет свою цену, и потому часть можно оставить в головах людей. И только после определения документов стоит выбирать, какими инструментами пользоваться: Wiki, Google Docs, что оставить в Task tracker и так далее.
Управление знаниями имеет еще один аспект, который находится за рамками проекта - обмен профессиональными знаниями между специалистами разных проектов. Здесь я рассчитываю поделиться практиками и кейсами, знакомыми мне из участия в сообществе Knowledge Management Russia, в конференциях которого я принимаю участие с 2010 года (отзывы на моем сайте http://mtsepkov.org/KM).
В целом доклад развивает мое выступление Agile и управление знаниями в ИТ-проектах на конференции KM Russia 15-16.12.2016.
Видео
Презентация
Скачать весь pdf