Решение проблем программным способом

Problem Solving: как эффективно решать проблемы в команде?

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

Способность своевременно решать внутренние и внешние проблемы продукта и команды и принимать ответственные решения — это то, чему должен учиться любой начинающий менеджер продукта уже на старте своей карьеры. В этом материале «разложим по полочкам» процесс problem solving, а также разберем несколько эффективных методик и упражнения для командной работы.

Грамотное решение проблем мотивирует членов команды достигать гораздо больших результатов, чем они могут себе представить.

Развивая навыки решения проблем, даже неопытный менеджер продукта на старте карьеры сможет улучшить командное сотрудничество и способность бороться со сложными ситуациями. Совместная работа побудит членов команды использовать разные стили мышления и принимать решения всем вместе.

В любом случае, совместная работа команды, направленная на решение бизнес-задач, — это не активность «ради галочки», и вам следует серьезно относиться к этому. Не важно, используете ли вы для этого простое упражнение, забавную игру или научный метод. Главное, чтобы любая problem solving activity принесла пользу и устранила очевидные и скрытые барьеры.

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

Независимо от размера и характера проблемы, системный подход к ее решению поможет вам стать более эффективным менеджером продукта.

В системном подходе к решению проблем можно выделить 5 основных этапов:

• Определение проблемы
• Выявление причин ее возникновения
• Генерация идей
• Выбор лучшего решения
• Действие

Определить проблему

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

К примеру, вы получили критический комментарий от одного из ваших пользователей/клиентов. Варианты решения вопроса будут разными в зависимости от того, как вы определяете эту проблему.

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

Выяснить причины

Как только проблема определена, стоит копать глубже и выяснить, что послужило ее причиной. Для определения причинно-следственных связей часто используют диаграмму Исикавы или диаграмму «рыбьей кости» (fishbone diagram).

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

Такой анализ достаточно эффективен, ведь он помогает убедиться в том, что ваши решения направлены на устранение фактических причин, а не на симптомы проблемы. Если найденное решение устранит лишь симптомы вместо фактической причины, то проблема, скорее всего, повторится.

Генерировать идеи

Как только сложная работа по определению проблемы и выяснению ее причин завершена, пришло время проявить творчество и начать «фонтанировать» идеями. Для этого отлично подойдут командные собрания и мозговые штурмы (brainstorming).

Выбрать лучшее решение

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

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

Или воспользоваться помощью доступных сервисов для управления продуктами, которые предлагают функции и инструменты для приоритизации. Таких, например, как Hygger, MindTools или ProdPad.

Действовать

Когда найдено идеальное решение проблемы, пришло время принимать меры. Если решение включает в себя несколько действий или требует дополнительных от других членов команды, рекомендуется создать план действий и рассматривать его как мини-проект.

Использование этого простого пятиступенчатого подхода, безусловно, повысит эффективность ваших навыков решения проблем.

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

Методики анализа причин и выявления решения проблем

Root Сause Analysis

Root Cause Analysis или RCA представляет собой действия, направленные на поиск ключевой причины возникновения проблемы, на ее анализ и создание плана по ее решению.

Часто в реальности сложно отличить симптомы от причины. Модель RCA нацелена на выявление происхождения проблемы и состоит из определенного набора шагов:

• Определение случившегося
• Определение причин случившегося
• Выявление шагов для того, чтобы это не повторилось

Проблема, чаще всего, будет включать следующие факторы:

• Физический фактор — проблема материальна и осязаема.
• Человеческий фактор, связанный с ошибкой определенного человека.
• Организационный фактор — когда какой-то процесс или система, используемые для принятия решений и выполнения задач, неисправны.

Для анализа всех граней негативного воздействия по RCA следует обратить внимание на все три фактора.

Принцип RCA во многом схож с другими методами и состоит из 5 последовательных шагов:

1. Определить проблему
2. Собрать необходимую информацию
3. Определить возможные причинные факторы
4. Выявить Root Causes
5. Предложить и внедрить решение

Важно уметь просчитывать, какой эффект может получить принятое решение.

CATWOE

Метод CATWOE, как вы понимаете, не имеет никакого отношения к котам (от англ. cat). Аббревиатура и сам метод полезен при сборе информации о проблеме.

Главный принцип техники заключается в декомпозиции проблемы на разные зоны влияния. Каждая начальная буква в аббревиатуре определяет зоны влияния: людей, среды и процессы.

• Customers — кто они и какие, как проблема влияет на них?
• Actors — кто вовлечен в проблему? Кого следует привлечь для решения проблемы?
• Transformation process — какие процессы затронуты данной проблемой?
• World view — какая общая картина происходящего? Предвидятся ли глобальные последствия?
• Owner — кто владеет процессом/ситуацией и какую роль сыграет в решении?
• Environmental constraints — есть ли ограничения, которые могут повлиять на конечный результат?

Все эти шесть элементов открывает новые перспективы и помогают углубиться в изучение проблемы. Метод CATWOE предоставляет более комплексные данные по проблеме и помогает определить серьезность проблемы перед активным вовлечением в решение других членов команды.

Техника 5 Why

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

5 Why использует 6-шаговый поток:

• Сбор команды. Обсуждение должно собрать тех, кто имеет непосредственное отношение к проблеме.
• Определение проблемы, если она не определена. С определением должны быть согласны все члены команды.
• Главное «Почему?». Задайте вопрос, почему проблема возникла. При ответе используйте только факты без домыслов.
• Остальные «Почему?». На полученный ответ снова задайте вопрос «Почему?». Продолжайте так, пока главная проблема не будет найдена. Таких вопросов может быть не пять, а больше или меньше.
• План действий. Когда команда выявила первопричину, самое время обсудить список мер и действий, чтобы избежать повторения проблемы в будущем.
• Анализ. Для неповторения проблемы в будущем также очень важен анализ. Обсудите насколько эффективными были предпринятые меры, помогли ли они избавиться от проблемы или снизить ее влияние. Если поставленная цель не была достигнута, необходимо повторить процесс.

Здесь важно быстро переходить от ответа к следующему вопросу, что позволит определить общую картину прежде, чем сознание составит суждение о проблеме.

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

Деловые игры для решения проблем

Деловые командные игры – это более неформальный вариант решения проблем. Чаще всего, такие активности направлены на развитие командной коммуникации, взаимовыручки, делегирования, адаптации и других полезных команде качеств и умений.

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

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

Egg Drop (Яйцепад)

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

Участников можно разбить на несколько команд. Каждая получает по яйцу и выбирает «строительные материалы». У всех будет 15-20 минут для того, что построить защитный «ларец» для яйца, которые не позволит ему разбиться. После чего участники сбрасывают свои «ларцы» с заранее определенной высоты (стол, этаж здания, лестница). Контейнер с яйцом не разобьется у сильной и сплоченной команды. Если уцелеют несколько яиц – можно увеличить высоту для эксперимента, пока не определится лучшая команда.

Тонущий корабль

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

Отметьте ограниченный участок на полу с помощью веревки или скотча. Команда должна поместиться в обозначенную территорию. Теперь постепенно сокращайте ограниченное пространство в течение некоторого времени. Участники должны найти способ удержать друг друга внутри и не упасть за борт «корабля». Обычно активность длится до 10 минут.

Квест

Развивает навыки командной работы. Все что необходимо – это ключ, запертая комната и 5-10 подсказок-заданий.

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

Минное поле

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

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

Поделите участников по парам, одному из партнеров завяжите глаза. Второй партнер должен направить и провести напарника из одного конца в другой, чтобы не задеть ни один предмет на «минном поле». Направлять можно только с помощью слов. Если запустить на поле несколько пар одновременно, задача усложнится.

«Слепая» фигура

Активность также полезна для развития коммуникационных навыков. Для проведения понадобится веревка и повязки на глаза.

Участники активности должны надеть повязки на глаза и стать в круг. Веревка связываются вместе и укладывается перед участниками также в форме круга. Ведущий игры называет геометрическую фигуру, которую участники должны изобразить с помощью веревки. Играющие могут переговариваться, но снимать повязки нельзя. Победит команда, которая быстрее построит необходимую фигуру.

Заключение

Еще ни один продукт не избежал мелких или крупных проблем в своей жизненно цикле. Возникновение проблем – это нормально. Главное вовремя обратить на них внимание и принять правильные меры. Для этого и существуют разнообразные методы решения или командные упражнения. Практика показывает, что они неоднократно выручали команды и помогали найти успешное решение.

А какими методами, упражнениями, командными играми и другими практиками пользуетесь вы для преодоления преград в жизни вашей команды, продукта, компании?

Источник

7 самых неприятных проблем в программировании

Известно, что на старых картах, на неизведанных территориях, часто помещали зловещее предупреждение: «Здесь живут драконы». Вероятно, смысл этого предупреждения состоял в том, что не стоит входить в это пространство мира, не будучи готовыми сражаться с внушающим ужас противником. Всё что угодно может случиться на этих загадочных просторах, и нередко такое «что угодно» может закончиться очень плохо.

Программисты, возможно, являются несколько более цивилизованными, чем средневековые рыцари — однако это вовсе не означает, что современный технический мир не имеет своих технических драконов, поджидающих нас в непредвиденных местах: сложные проблемы, которые всплывают именно тогда, когда подходит срок сдачи работы или в моменты особенно высоких нагрузок и ответственной работы; конкуренты, которые прочитали руководство и знают, что недостаточно хорошо реализовано; злые «бесы», которые знают, как использовать неустранённые до конца баги и дефекты программ, причём узнают это часто сразу же после того, как программа сдана в использование.

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

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

Многопоточность

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

Идея работает — когда все части являются, действительно, полностью раздельными и никак не связаны друг с другом. Но если они должны получать доступ к одним и тем же переменным или записывать биты в одни и те же файлы — игра окончена. Какой-то из потоков выйдет на эти данные первым, и невозможно предсказать какой.

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

Когда и если они не работают, то воцаряется хаос. Получаемые данные теряют смысл. Столбцы не стыкуются. Деньги исчезают со счетов со свистом. И это всё — просто биты в памяти. И большая удача, если удастся определить какой-либо из них. В большинстве случаев разработчики заканчивают тем, что блокируют значительные участки структуры данных так, чтобы только один поток мог взаимодействовать с ними. Это позволяет остановить хаос, но только за счёт ликвидации большей части положительных сторон наличия несколько потоков, работающих на тех же данных. Вы просто могли бы переписать такую программу как «однопоточную».

Замыкания

Где-то по ходу дела кто-то решил, что было бы полезно передавать функции, как если бы они были данными. Это работало хорошо в простых случаях, но программисты начали осознавать, что возникают проблемы, когда функции стали выходить снаружи на самих себя и получать доступ к другим данным, часто называемыми «свободными переменными». Какая версия является правильной в этом случае? Данные на момент инициализации вызова функции? Или же на момент её фактической работы? Это особенно важно для JavaScript, где данные моменты могут быть сильно разнесены.

Решение — «замыкание» — является одной из самых больших причин головной боли для программистов JavaScript (а теперь и Java и Swift). Новички и даже многие опытные программисты не могут понять, что замыкается и где могли бы быть границы этого так называемого замыкания.

Название не помогает — это не похоже на предупреждение о постоянном закрытии доступа вроде предложения для посетителей паба сделать последний заказ (перед его закрытием). В любом случае доступ открыт, но только через «червоточину» в континууме данные-время — странном механизме сдвига во времени, который, должно быть, навеян научно-фантастическими сериалами. Но названия «комплексный механизм доступа к стеку» или «система манипулирования управлением данными» представляются слишком длинными, поэтому было выбрано «замыкание». И не будем начинать разговор о том, кто должен поплатиться за несвободные переменные.

Слишком большие данные

Когда ОЗУ начинает переполняться, всё падает. Не имеет значения, выполняете вы навороченный статистический анализ потребительских данных или работаете с привычной старой электронной таблицей. Когда машина выходит за пределы ОЗУ, то она обращается к т.н. виртуальной памяти, которая действует на чрезвычайно медленном (по сравнению с ОЗУ) жёстком диске или твердотельном накопителе. Это, конечно, лучше, чем полная остановка или завершение задания, но работа замедляется в любом случае.

Проблема в том, что быстродействие жёстких дисков в 20-30 раз меньше, чем у ОЗУ, а накопители, массово продаваемые на рынке, работают ещё медленнее. Если какой-то другой процесс также пытается в это время писать на диск или считывать с него, то ситуация становится просто драматической, поскольку эти накопители могут выполнять только одну задачу в каждый момент времени.

Активация виртуальной памяти обостряет другие, скрытые проблемы вашего программного обеспечения. Если имеются какие-то потоковые дефекты, то они начинают проявляться намного сильнее, поскольку потоки, попадающие в виртуальную память на жёстком диске, обрабатываются намного медленнее, чем другие потоки. Другие потоки «подвисают» лишь на то время, пока поток-неудачник находится в этой памяти. Если программа сделана хорошо, то результатом является заметное замедление. Если в программе есть дефекты, то они быстро приводят к катастрофе. И это лишь один маленький пример.

Управление подобной ситуацией является серьёзным вызовом для программистов, оперирующих большими наборами данных. Любой, кто хоть немного расслабляется при проектировании структур больших наборов данных, неизбежно заканчивает программой, работающей неприемлемо медленно. Она сможет нормально пройти несколько тестов, но реальные нагрузки отправят её штопором в отказ.

NP-полная задача

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

Проблемы NP-полной задачи часто являются довольно сложными — если пытаться решить их, используя просто грубый, силовой подход. Например, длительность решения «проблемы коммивояжёра» растёт экспоненциально по мере увеличения количества точек маршрута. Решение «задачи о рюкзаке» нахождением подмножества чисел, которые подходят ближе всего к некоторому значению N, требует перебора всех возможных подмножеств, число которых чрезвычайно велико. Все с опасением стараются уйти от этих проблем, потому что они являются примером одного из самых страшных компьютерных «монстров»: немасштабируемые алгоритмы.

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

Существование таких довольно хороших решений делает «драконов» только более загадочными. Никто заранее не может быть уверен, действительно ли трудны эти проблемы или же они могут быть сравнительно легко решены — если вас устроит ответ, который будет просто хорошим.

Безопасность

«Есть познанное знание — то, о чём мы знаем, что знаем», — сказал однажды на пресс-конференции Дональд Рамсфельд, министр обороны второй администрации президента США Джорджа Буша. «Есть также познанное незнание — то, о чём мы знаем, что не знаем. Но есть ещё и непознанное незнание — это то, о чём мы не знаем, что не знаем.»

Рамсфельд говорил о войне в Ираке, но то же самое справедливо и для компьютерной безопасности. Самой большой проблемой являются дыры, о которые мы даже не знаем, что они возможны. Все понимают, что необходимо сделать свой пароль трудным для разгадки; это — познанное знание. Но кто-нибудь когда-нибудь хотя бы говорил, что ваше сетевое оборудование имеет свой собственный программный уровень, спрятанный глубоко внутри? Возможность не заниматься взломом вашей ОС, а вместо этого нацелиться на данный «секретный» уровень является непознанным незнанием.

Возможность подобного проникновения можно теперь не рассматривать как «непознанную», но ведь могут существовать и другие? Мы не имеем ни малейшего понятия, возможно ли заделать дыры, если мы даже не знаем, существуют ли они. Можно тщательно защитить пароли, но существуют способы взлома, которые мы не можем даже представить себе. Работа с компьютерной безопасностью доставляет, несомненно, море удовольствия. А когда речь идёт о программировании, то мышление, ориентированное на безопасность, становится всё более важным. Нельзя перекладывать на профессионалов, занимающихся безопасностью, расчистку созданной вами путаницы.

Шифрование

Шифрование кажется мощным и неприступным, когда сотрудники правоохранительных органов стоят перед конгрессом и просят дать им официальные входы в программы, чтобы преодолеть его. Проблема состоит в том, что основная часть шифрования построена на туманном облаке неопределённости. Какие математические доказательства у нас есть для неясных допущений, вроде того, что трудно разложить на множители действительно большие числа или провести дискретное логарифмирование?

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

Реально сложной задачей является использование шифрования в собственном коде. Даже если базовые алгоритмы, как мы полагаем, безопасные, должно быть сделано много работы по обращению с паролями, ключами и соединениями. Если будет сделана хотя бы одна ошибка и какой-то пароль останется незащищённым, то всё будет напрасно.

Управление идентификацией

Многие любят рисунок, опубликованный в газете «The New Yorker» в 1993 году, с надписью: «В интернете никто не знает, что ты собака». Он даже имеет свою собственную страницу в Википедии с четырьмя детально проработанными разделами. (В интернете мало кто знает старую шутку об анализе юмора и препарировании лягушек.)

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

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

Немногое из этого имеет значение для мира пустословия в Snapchat или Reddit, но множество взломанных страниц Facebook немного обескураживает. Нет какого-то лёгкого способа заниматься в сети серьёзными вопросами, такими как собственность, деньги, здравоохранение и в значительной степени всё остальное в жизни, кроме «светского» разговора на общие темы.

Фанаты биткоинов любят высказываться, насколько надёжным может быть блокчейн, но так или иначе биткоины продолжают воровать (см. здесь и здесь). Тут у нас нет никакого реального метода для идентификации.

Источник