KnowledgeConf 2019. Впечатления и отчет

Как и остальные ИТ-конференции, KnowledgeConf 2020 ушла в онлайн. Забавные докладчики в домашней обстановке на фоне обоев, кроватей и игрушек 😊. В личном кабинете – таблица текущих докладов со ссылками. С точки зрения докладов эта выставка мне понравилась меньше предыдущей. Много повторов одного и того же. Вроде как мы уже договорились, что обмен знаниями - хорошо, почему хорошо, насколько хорошо - и повторение одних и тех же постулатов в 80% докладов надоело.

Вместо одного дня доклады растянулись на целых два дня. Время докладов было поставлено очень странно: в одном зале доклад 15.00-15.45, в другом зале в 15.30-16.30, доклады перекрываются по времени, зачем это было сделано – я не поняла. Во время обеда тоже были доклады, причем по времени они тоже смещены (либо на конец не попадаешь, либо на начало). Вопросы и дискуссии все были перенесены в Zoom.

Расписание

Презентации

Каталог ресурсов

Карта ролей

День 1

Как продать проект по менеджменту знаний руководству

Описание

Оценка: 3/5

Докладчик из Росатома в зуме рассказывал понемногу обо всем.

Как миддл может обосновать необходимость внедрения системы знаний. Как правило, напрямую топ-менеджмент не заинтересован в системе знаний, поэтому предложение по внедрению надо “грамотно обернуть”, например, расписать выгоды от снижения внутренних издержек. Варианты целеполагания внедрения СУЗ:

• снижение рисков;
• снижение внутренних издержек;
• повышение капитализации.

Снижение рисков – страхование от утраты компетенций команды. Повышение капитализации: нематериальные активы, выявленные знания, опыт. Выявить уникальные компетенции и наработанный опыт, коммерциализировать (разработать продукт, услугу…).

Вопрос: Как считали деньги по экономии на найме и консультантам? Ответ достаточно расплывчатый. Как я поняла по консультантам: у них есть компании-“дочки”, в которых есть сотрудники на зарплате. Поэтому считали затраты на внедрение СУЗ и тиражирование и содержание таких дочек.

Последствия невнедрения СУЗ:

• утрата уникальных знаний, критических компетенций, опыта;
• знания не приносят доход, рост аутсорсинга;
• снижение привлекательности компании для новых сотрудников

Управление знаниями в Росатоме рассматривают как управление проектами. Управление знаниями является неотъемлемой частью управления проектами (несколько цитат из PMBook). Рассказал про производственную систему Росатома (распиаренная практика, ссылка, см. брошюры).

Дальше пошло про крупный бизнес, стало неинтересно.

5 критериев неэффективной базы знаний и способы все исправить

Описание

Оценка: 4/5

Knowledge-Centered Service - практика по управлению знаний, консорциум. Речь дальше пойдет про публичную базу знаний (доступную клиентам).

Критерий №1: сотрудники прокачиваются, получают знания, а время решения вопросов не сокращается.

Выяснилось, что решение сотрудники писали в личные заметки, а не в общую базу. Две причины, почему сотрудники не пишут в общую вики: не хочу и не могу.

• Не хочу = не вижу выгоды для себя. Эффективная цель (одна из) – каждая заявка (задача) заканчивается статьей или описанием;

• Не хочу = мне это не нравится, я не хочу тратить время. Решение: кнут/пряник;

• Не могу = не знаю, как делать. Решение: внутренние гайды, сделать шаблоны для статей.

  • Пример: Question/Answer, How to
  • Troubleshooting: Sympoms, Cause, Resolution

Критерий №2: База знаний растет, количество клиентов увеличивается, а вопросы от них все те же.

Проблема: решение описано с точки зрения сотрудника, а не клиента (“проклятие знания”).

Критерий №3: Вы сделали крутые онбординг-тренинги, но новенькие все равно буксуют.

Научить простым вещам: как искать статьи, где искать. Нужно улучшать существующие статьи, а не писать постоянно новые (да!!!!).

Критерий №4: Только ограниченный круг людей пишет в базу.

Привлекали только технически подкованных людей: получилось плохо - статьи слишком сложные и найти трудно. Люди, которые записывают знания, но не используют их - быстро теряют экспертизу.

В результате они разрешили писать в базу всем сотрудникам. Стали записывать только те знания, которые необходимы (в их случае - если есть вопрос от клиента - нужна статья). Что дает подход: рост экспертизы быстрее на 70%, поддержка актуальности статей.

Критерий №5: ни новые фичи, ни фиксы не улучают NPS продукта, либо улучшают незначительно

Пришлось гуглить, что такое NPS

Zettelkasten: организация персональной базы знаний

Описание

Оценка: 2/5

TLDR: похож на прошлогодний доклад про Тиаго Форте, Evernote и на mindmaps. Но в это время никаких других докладов не было, пришлось слушать, что дают.

Идей много, они приходят постоянно. В голове все не помещается. Просто заметки не работают. Просто информация не является знанием. Есть ли методика?

Zettelkasten («ящик заметок», нем):

• простой способ организовать заметки в связанную структуру;
• полезен: для хранения знаний, продуктивного чтения, синтеза новых знаний из контента.

Основа:

• атомарные заметки;
• но связанные между собой.
• ссылки между заметками;
• тэги;
• аутлайны – общее оглавление со ссылками.

Тэги круче иерархии. (Наверное, на маке сидит).

Презентация Pragmatic Knowledge Guide

Описание

Презентация

Сам гайд

Оценка: 3/5

Как начать внедрять лучшие практики Knowledge Management. По сути – обзор/продвижение гайда профессионального сообщества: вики-система с описанием практик и рекомендаций по внедрению.

Существует большой разрыв в управлении знаниями между ИТ и реальными секторами экономики (врачи, полиция и т.д.). То есть то, что ИТ-шникам достаточно легко, остальным – гораздо сложнее. Хотелось бы сократить разрыв и как-то унифицировать практики и рекомендации по управлению знаниями.

Фокус гайда:

• как войти и начать изменения (приступить к началу решения проблемы :));
• какие существуют практики.

Как начать изменения:

• как понять что не так?
• как добиться быстрых побед? с помощью схем, чек-листов, разговоров. Чтобы внедрить систему знаний, нужно «продать» идею как можно большему числу коллег. Чтобы тебя слушали, нужен авторитет. Авторитет можно нарабатывать этими «быстрыми победами»;
• работа с людьми и изменениями.

Практики управления знаниями:

• онбординг и найм;
• фиксация знаний;
• культура обмена знаний;
• выученные уроки, лучшие практики;
• KCS;
• формирование отдела KM.

По каждой теме в гайде:

• общая вводная;
• выделенные практики;
• способы (лекция от тимлида, приветственное письмо, handbook)
• понятные источники и авторы;
• вопросы, на которые нужно найти ответы;
• практики и что может пойти не так.

Вики-платформа – гитлаб. Дальше пошло техническое описание как коммитить в гитлаб, и что дальше будет с этим гайдом.

Как мы собираем проектный опыт компании (КРОК)

Описание

Оценка: 4/5

В начале про КРОК, какие они замечательные и чем занимаются. Более 2000 проектов.

Фокус управления знаниями в КРОК: быстрый поиск релевантной информации для релевантных целей, обмен опытом, развитие культуры обмена знаниями, развитие ресурс-менеджеров как knowledge managerов.

Далее был пример обмена знаниями в рамках конкретного внутреннего проекта (сервиса) “Проектный опыт”. Сервис “Проектный опыт”:

• база проектного опыта;
• помогает готовить конкурсную документацию, компетенции и пр. для тендеров;
• один из инструментов онбоардинга для менеджеров.

Сервис включает::

• оперативные карточки проектов (описание, сроки и пр.);
• четыре вида отчетности;
• формы сбора опыта (карточки, которые заполняют и согласуют все участники);
• процесс согласования опыта.

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

С чего начинали: большая база, участники не понимали, зачем нужно поддерживать базу. Не были собраны use-case.

Что сделали:

• собрали честную обратную связь (почему люди не делятся знаниями - не хочу, не могу, не нравится мне ваша система….);
• посчитали реальные цифры: сколько компания теряет на не собранном в одном месте опыте;
• пересобрали рабочую группу: входят представители разных отделов (менеджеры, сейл, ит, маркетинг, службы). Рабочая группа собирается раз в неделю. Каждый ччлен группы отвечает за свою зону. Введен trello для отслеживания и распределения задач;
• выработали четкий план: сбор информации по проекту, сбор требований и реализации, создание отчетности, наполнение базы, пиар среди коллег;
• выработали и согласовали с топ-менеджерами метрики.

Метрики:

• заполнения (доля проектов в сервисе, длительность шагов..);
• использования (доля сотрудников, которые используют);
• общих показателей (общая оценка сервиса).

Мотивация:

• их внутренняя система геймификации (они буквально на всех конференциях ее показывают);
• необходимость внесения информации по проекту для его закрытия.

Как поддержать актуальность информации в базе знаний службы сопровождения ИС

Описание

Оценка: 3/5

Вводная часть - стандартные дифирамбы СУЗ. Неактуальный кейс (статья) – всегда затраты. Затраты на поиск решения, на создание дополнений к кейсу, на дополнительные согласования. Виды актуализации:

• врЕменная – срочно среагировать и поправить;
• регламентная - при выпуске версии;
• постоянная.

Алгоритм обновления: вытащить с помощью тегов/категорий все материалы для обновления, согласовать концепцию обновления (удаления, объединения), внести корректировку, обновить и оповестить об изменениях.

Что помогает быстро адаптироваться:

• ключевые слова в заголовке документа и в тексте;
• детальная классификация – по типу, статусу, подсистеме. Классификаторы по влияющим факторам (например, для гос.систем – закон, номер доработки и пр.).
• по тегам – по функциям, по событиям.

Структура документа: вся информация по кейсу на одной странице + связь с иными кейсами

Исключить дублирование информации. Делают организационно (кнутом и пряником).

Лайфхаки: управление повторяющимися формулировками – короче, единый источник для документирования описала.

Выход версии системы. Способы актуализации:

• описание доработки по бизнесу – как понятно пользователю, было – стало;
• разметка статей по номеру релиза, где это решение актуально. При создании статьи отмечаем номер релиза, для которого она актуальна. При последующем обращении к статье, если требуется – проверить решения для новой версии и поднять версию.

Архивация: статьи, которые неактуальны, нужно архивировать (в идеале – убирать из поиска).

Что предусмотреть: тщательно продумать структуру, классификатор и гайд.

Zoom-говорилово от Цепкова – KM как дисциплина

Описание

Оценка: 5/5

Честно говоря, из всех активностей, пожалуй, понравилось больше всего. Фактически, это был монолог (рассуждение на несколько тем) про суть знаний, их философские и научные аспекты. Ну и вначале, конечно, обсудили трепещущие вопросы виртуальных фонов зума.

Тезисно, о чем говорили:

• Явные и неявные знания. Выявление и передача. Тейлор против Нонака и Такеучи. Устная традиция как годное средство - но в современном варианте, фреймворк за квартал по всему миру.
• Спектр формальности мышления, рациональные и интуитивные знания. Схемное, визуальное и текстовое представления. Левенчук “Утопия визуального мышления”. Тут обсудили современные тенденции к сокращению текстов и ухудшению восприятия длинных и сложных текстов.
• Фокусировка от задачи. Управлять по площади - точно не хватит ресурсов.
• Проекты в долгую при текучке в команде. Управленческая позиция против архитектурной, архитектор вечен, менеджер - нет. На самом деле - никто не вечен :)
• Люди хотят делиться знаниями. 1-2-6-1 - статистика (один - энтузиаст, 2 - не против поддержать, 6 - будут делиться, если записано в должностной инструкции, 1 - не будет делиться, просто потому что не хочет). Даже в культуре индустриального общества.
• Знание - все-таки средство, а не цель и не самостоятельная ценность. Есть области, где не так - теоретическая наука.
• Систематичность на масштабе: Человек - Команда - Компания (сообщества в ней) - Профессии и Отрасли.

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

Новое поколение не способно воспринимать длинные сложные тексты. Однако, большие сложные концепты не покажешь визуально. По сути, скилл чтения, восприятия и анализа текста становится “элитным”. Тренировка только в детском возрасте: читать быстро (на время) и пересказывать.

Совет! Если вы хотите, чтобы люди начали обмениваться знаниями — не начинайте с документации. Корректное, экологичное внедрение документации — это задача уровня advanced, а никак не beginner. Мало написать документацию (что само по себе сложная задача) — её должны читать и обновлять. Мало её написать один раз — ей должны заниматься постоянно. Насилие не решает проблемы: документация превратится в пустую филькину грамоту и профанацию. Жизнь меняется и формат зафиксированных знаний тоже должен будет эволюционировать, самодурством этого не добьёшься — нужна культура.

Начните лучше с того, чтобы люди начали разговаривать. Чтобы не боялись задать вопрос кому угодно о чём угодно. Чтобы рассказывали о том, о чём важно рассказать.

День 2

“Стартовый пакет” коммуникаций для отдела ручного тестирования

Описание

Оценка: 4/5

Клевая презентация с миньонами! TLDR: еще раз про онбординг

Катастрофы из-за плохих коммуникаций: срыв сроков, дублирование работы. Не проговариваются очевидные вещи: «зачем это проговаривать, и так все понятно». Тестировщики входят в новый проект. Как разобраться и с кем коммуницировать?

Какие коммуникации нужны новеньким qa:

Уровень 1: одинаковый для всех отделов: как тут что устроено и где про это можно прочитать/узнать. Значит должно быть место, где вся необходимая вступительная инфа написана.

Welcome book: про график работы, часы работы, порядок коммуницирования с руководителем. Про болезнь (выходить на работу больными плохо, кто бы сомневался). Отпуска – график с уведомлением. Трэкинг времени и worklog. Чтобы вносили время и ворклог – аккаунт менеджер проверяет каждую неделю, кто внес, кто не внес трэки. Инструменты: интранет/wiki, нотификации в slack

Уровень 2: шеф, а что делать-то?

Вход в проект, разработана система ввода новичка в проект:

• краткое описание проекта, сроки, дэдлайны, принцип работы (шаблоны, примеры) – QA Guide. Первый день в проекте, в чем ваша роль, FAQ…..
• знакомство с командой: кто за что отвечает в команде, к кому обращаться и т.п. Какая деятельность в деплое?
• заказчик: коммуникация с заказчиком. О чем надо договориться на входе с заказчиком: короче ТЗ (не забыть про репорты (формат, регулярность), спринты, география команды, состав команды. Зафиксировать договоренности (протоколы совещаний)). разделение задач и зон ответственности. Мир с другими отделами: особенно с разработчиками. Разработать шаблон описания бага: где найдено, шаги воспроизведение, скрин, нормальный заголовок, назначить задачу, логи.

Уровень 3: нравится или не нравится работать в компании?

• важно спрашивать «Как дела», «что не получается», «чем помочь?». Тет-а-тет
• велком дэй: знакомство с руководством, чтобы знать руководство и понимать, что они не страшные. Раз в месяц/квартал для всех новеньких

Нужна или не нужна база знаний? Прежде всего необходимо определить цель создание БЗ. Определить инструменты.

Отчего базы знаний не взлетают: непонятно, как искать и куда записывать? Нужно: проводить краткий ликбез, как работать с базой знаний. С чего начать? структура + онбординг гайд Как внедрять? постепенно. Мотивация? А оно мне зачем? Нужно объяснить зачем. Короче, как в браке, основа благополучия - коммуникация.

Запускаем и отлаживаем внутренние митапы

Описание

Оценка: 5/5

Зачем нужны кому-то внутренние митапы? – оставил за скобками 😊. Типа у всех по-разному. Главные причины, почему возникали – потому что захотелось группе энтузиастов. Сверху, как правило, не работает.

Разобрал две ситуации:

• ситуация 1 – внутренних митапов нет, но хочется. Что делать?
• ситуация 2 - внутренние митапы есть, но как-то вяло

Ситуация 1

Модель Уилбера (Уилбер - киношный злодей справа):

Если вы хотите добавить что-то во внутреннюю культуру компании (например, митапы), то, что, вы можете предпринять – действовать по 3 направлениям (со стороны остальных трех квадратов).

• вовлекать лидеров (формальных/неформальных) – поведение сотрудников;
• учить лечить мочить – убеждения и установки сотрудников;
• менять процессы – организационные системы (формат проведения, порядок выступления, мотивация).

По каждому пункту приводил длинные и очень подробные примеры.

По митапам – опрос (спросить людей, что думают), о чем интересно услышать, кто из коллег занимается чем-то интересным? “Расскажи о своем проекте – что сложного? что придумал необычного?” Митапы необходимо модерировать. Нужно собирать обратную связь.

Итого: запускаем внутренние митапы

Вовлекаем лидеров, чтобы показывали пример

• На примере отчетов-докладов раз в N времени
• Лично договариваться с руководителями, чтобы выступили
• Выступать самостоятельно

Делаем процессом

• С формальными атрибутами
• Часть других процессов, например, ретры
• Прием: переходящее знамя

Мониторим настроения сотрудников:

• Опросы
• Моделрация
• Обратная связь

Ситуция 2. Митапы есть, но вяло идут. Что делать?

Если человек, чего то не делает, то, как правило, на это есть 4 причины:

• (1) не умеет – показать примеры (подготовить шаблоны презентаций, дать структуру). Показать советы (рекомендации). Помогать готовить доклад.
• (2) не понимает цель – переиспользование опыта, скорость и стоимость принятия решения, расширение кругозора
• (3) не может – помочь (не всегда работает)
• (4) не хочет – оставить в покое (заставить скорее всего никак нельзя, кроме как денежной мотивации), попробовать спросить еще раз через некоторое время,

Итоги: отлаживаем внутренние митапы Не умеет:

• показать референсы
• рассказать советы
• помочь приготовиться

Не понимает цель:

• переиспользовать опыт
• расширить кругозор
• прокачивать soft skills

Не может: помочь Не хочет: остаить в покое

Lightning Talks 2

Описание

Оценка: 3/5

Lighting Talks - 3 доклада, каждый по 10 мин., потом идет обсуждение.

Краткие тезисы и впечатления: “Создание знаний в организации, обеспечивающих конкурентоспособность” - слишком перегруженный для 10 мин. доклад. Очень много терминов, нет примеров для привязки к реальному миру.

“Глубокое погружение: эволюция системы обучения как залог успешности команды и проекта” - Взгляд на онбоардинг и планирование обучения. Пример таблички:

“Стратегия компании и ее знания: а есть ли связь? и как ее установить? “ - достаточно спорный доклад по выявлению критических знаний по отношению к другим компаниям. Типа мы должны посмотреть, какие знания есть у конкурентов, какие у нас, и на основе этого разработать стратегию, чтобы стать лидером.

Внутренняя документация в компании: необходимое и достаточное

Zoom-дискуссия

Оценка: 5/5

Как определить какая документация нужна, какая нет и как определить, что нужно, что не нужное. Какая внутренняя документация для нового сотрудника должна быть? Например, для программистов: «курс молодого бойца»: инструкции, репозитории, инструменты, контакты. Нужно подумать, что нужно передать новичку, и, в зависимости от ЦА, выбрать формат.

При фиксации знаний всегда важно держать в голове кому они адресованы.

Нужно ли ставить гриф, что документация является «внутренней» и ее нельзя распространять внешним клиентам/заказчикам. Небольшая дискуссия про конфлюенс, разделение платформ для внутренний и внешней.

Какая внутренняя документация маст-хэв: мнения разделились. Ник: Для аналитиков/менеджеров – условное ТЗ (vision, что должны получить в результате, что должно быть сделано). Для разработчиков – выбор технологии, отчет по прототипированию, гайд. Инфраструктурные менеджеры: RCA (root cause analysis) – что сломалось, что починили и что сделать, чтобы больше не ломалось.

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

Следующий вопрос для обсуждения: терминология – внутренняя vs внешняя. Глоссарий. В документации для внешних пользователей нужно говорить языком пользователя, чтобы он понял. На англ. языке, как правило, рекомендуется использовать simple english.

Как вытягивать знания у людей, которые не хотят ими делиться, и разрабов, у которых нет времени на объяснения? В большой степени – софт скиллы + организационные..

Как мотивировать писать документацию разработчиков? Спросили разрабов – почему не хотят писать? Они:

• мы не можем писать как технический писатель, боятся что их не поймут. Какой выход? Сделать шаблон. Пишите, как хотите, я как, тех писатель – переведу.
• Я разработчик, “что, я должен писать документацию??!” Обычно это решается – няшки, аттестация, обязательность для закрытия задачи.
• разработчикам часто тяжело (не ПЛОХО, просто тяжелее) писать буквы. Упростить задачу входа – сделать шаблоны, проработать гайд, научить писать. Обычно хороший инженер хорошо формулирует мысли. Зудит в голове, что он занимается непрофильной активностью, и ему надо не писать – а фиксить баги. Тут надо сказать, что ты пиши, мы доработаем. Важно дать понять, что разработчик пишет для внутренних потребностей, а для внешних техпис переработает (снять ответственность).

Культура и привычка. Один человек не может драйвить всех. Требуется изменение культуры (сверху, снизу).

Как с помощью одного проекта систематизировать корпоративную базу знаний, подружить коллег и увеличить лояльность клиентов

Описание

Оценка: 3/5 (ненавижу рекламу)

Практический кейс. Компания занимается интернет-рекламы: автоматизация закупки рекламы. Автоматически находит ЦА и показывает рекламу только им. Full-service – компания сама делает, Self-service – компания обучает клиенты потом сами.

Внутренние боли, как поняли что нужна СУЗ:

• разрозненная коммуникация между командами;
• необходимо поддерживать высокий уровень знаний (специфическая область)
• временные затраты на онбоардинг.

Внешние задачи:

• обучение клиентов;
• перевести с фулл сервис на селф сервис
• повысить лояльность клиентов.

Сделали не базу знаний, а онлайн-курс. Плюсы:

• единая точка входа;
• структура и последовательность;
• для разного уровня знаний;
• разные форматы материалов;
• автоматизированное тестирование;
• видим статистику и прогресс;
• можно выявить проблелы.

Как работали:

• сначала разработали структуру курса (на основе статей из БЗ, обучающих видео, типичных вопросов, публичных выступлений). Логика: от общего к частному, от теории к практике. Три модуля: общая теория, работа в платформе (практика, примеры), аналитика – оптимизация, процессы работы. Два уровня: теория (курс + тестирование), практика (практическое задание).
• назначили ответственность, обозначили дэдлайны;
• сбор материала, проверка;
• стилизация текста;
• финальная проверка.

С чем столкнулись:

• очень много информации;
• инсайты;
• разница в описании инструментов;
• синдром профессионала (проклятие знания) – человек, которому рассказываете не имеет вашего бэкграунд. Нужно предугадывать вопросы.

Как выбрать формат? Картинки спасут мир, текст + иллюстрация. Описание урока: краткое описание урока, содержание, чтобы проще было найти нужный. Скринкаст-инструкции для практических уроков. Как записать лекцию, когда эксперт – не спикер? Делить видео на мини-фаргменты по 2-3 предложения.

Lightning Talks 3

Описание

Оценка: 4/5

Практика применения KPI в отделах по управлению знаниями

Пересказ исследования (опросов) по разным компаниями (есть ли такой отдел, чем занимается и т.д.). Понемногу обо всем.

Как организовать доставку знаний на протяжении всего бизнес-процесса?

Проблема и идея: есть хаос знаний – на нового сотрудника вываливают много информации. Нужен именно гайд, структура, поэтапное вовлечение.

Система знаний которая встроена в бизнес-процесс компании. «Навигатор по процессу». Как я поняла это система помощи в системе, которой работают менеджеры. Показывали демо.

Common code — путь самурая

О чем: много технических специалистов пытаются затаскивать в систему знаний то, чего там быть не должно (?). Про переиспользование кода/знаний/опыта с примерами.

Как знания о мире влияют на классификацию задач в разработке ПО

Описание

Оценка: 3/5

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

Полнота знаний о мире. Паззл как пример. Что находится на неизвестном куске паззла? То есть знание об объекте у нас 0,75. Нужно ли пытаться выяснять что на недостающем куске, насколько это важно? (Спойлер: там дракон:))

НИОКР – как этап работы. Фактическую работу стоит начинать, когда знаний по крайней мере больше 50%. Разработка ПО – это как правило ИОКР: поиск новых знаний, проверка теоретических положений, анализ и синтез, реализация опытного образца. Также стоит наверное заметить, что мы редко когда «начинаем» с нулевых знаний.

Проблема: что-то мы медленно разрабатываем ПО. Нужно чтобы функции появлялись как можно быстрее и как можно лучше удовлетворяли требования. Обычно решают так:

• найм – нанять больше людей! Нанимают людей… а работа не ускоряется, а даже замедляется
• разработка – недостаточно хорошо организован процесс разработки. Все наладили, но проблема не пропала – то, что производим, никому не нужно
• бизнес – наверное мы неправильно понимаем, что хочет бизнес?

Я скажу сразу спойлер вывода, так как далее докладчик ооооочень подробно расписывает примеры по каждому пункту, я прям устала.. Докладчик предлагает идти от последней проблемы к первой. То есть сначала выяснить, чего хочет бизнес (восполнить знание), тогда, вероятно, не нужно вносить изменения в разработку, и не нужно нанимать сотрудников. Или нужен сотрудник совсем другой квалификации. Короче, знание - сила.

Примеры для найма. Типичный найм: стек, поток, собеседование, выбор. Насколько полно технический специалист описывает человека, которого нужно найти на должность? Обычно дают только стек опускают остальное (софт-скиллы, специфические требования). Но если сначала провести исследование (потрясти технического специалиста), то выяснится, что часть требований не нужны, часть важных требований забыли упомянуть. Поэтому зачастую, рекомендуют описать для начала уже существующую в компании роль. Привел пример: искали долго сотрудника программиста Java с многопоточностью. Не могли найти, все не то. Потом решили уточнить, где же там в проекте нужна эта многопоточность, выяснилось - что это понадобится только через 3 мес. и на базовом уровне (быстро можно обучить). В результате быстро нашли нужного специалиста и стоил он несколько дешевле.

ИОКР: Кто нужен? Вакансия. Собеседование. Подбор.

Ссылки

• Интересный отчет по потерям компании при неэффективном управлении знаниями (ссылка)
• Прагматичный гайд по Управлению Знаниями