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

Даннинг и Крюгер получили за это исследование Шнобелевскую премию, между прочим.

Push- и pull- подходы в управлении
#терминология

Подобно тому, как есть push- и pull-стратегии продвижения товаров, книга "Impact Mapping" дает определение push- и pull-подходам в управлении. Как можно догадаться из названия, push-подход подразумевает, что по цепочке сверху вниз поступают указания, что и как сделать, а pull-подход подразумевает, что команде обозначается проблема/желание заказчика, а участники команды сами решают, как эту проблему решить/как лучше реализовать желание заказчика. Это сдвиг фокуса внимания с того, что требует заказчик, на то, что ему действительно нужно.

Push-подход — это внешняя мотивация (делай в точности так, как сказал заказчик), а pull-подход — внутренняя (хочу разобраться, почему заказчик так сказал).

Сторифрейминг - формирование пользовательского поведения
#терминология #аналитика

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

Пользовательские истории говорят так: «Вот, что нам известно, или что мы думаем о деятельности клиентов»
Сторифрейминг говорит: «Вот то, что мы хотим, чтобы они сделали».

Читать будет интересно в основном бизнес-аналитикам и продуктологам.

http://uxgu.ru/storyframing/

Ну и раз сегодня зашла речь про пользователей, то вот)

Выявляя требования, старайтесь быть беспристрастными
#аналитика

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

— Не правда ли, будет здорово, если мы добавим на сайт вот этот раздел?
— Согласны ли вы, что добавление этого функционала не будет полезным для пользователей?

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

Вот какой эксперимент косвенно это подтверждает: группы исследователей в разных странах в рамках одного исследования, независимо друг от друга, составили опросники, где был в том числе вопрос, согласны ли люди после смерти завещать свои органы науке. Результаты оказались странными: в одних странах 99% жители были готовы помочь науке, в других же практически никто не согласился.

После долгих поисков причина была найдена. В разных опросниках содержались два варианта вопроса:

— ⬜️ - отметьте этот пункт, если вы хотите завещать свои органы науке.
— ✔️- снимите галку напротив этого пункта, если вы не хотите завещать свои органы науке.

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

Это работает во всех сферах: и в переговорах, и в рекламных письмах: если вы напишете "не хотели бы вы сделать...?", то ответ, скорее всего, будет "нет, не хотели".  Поэтому, выявляя требования, тщательно продумывайте задаваемые вопросы, если хотите получить действительно независимое мнение.

Никогда-нибудь - книга про то, как найти любимую работу
#ap_книги

Дочитала "Никогда-нибудь" от издательства МИФ.  Большинство книг, которые я сейчас читаю - от них, потому что мне нравится мысль, что издатели сами читают книги и издают только те, что понравились им самим.

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

Подойдет как консультация карьерного специалиста тем, кто хочет что-то поменять, но не знает, как и на что. Мне не подошла - мне нравится моя работа :) Но тем не менее, читать было интересно и несколько стереотипов было разрушено - например, что не всякий свой бизнес лучше работы в офисе, и что не всегда хобби можно сделать любимой работой. А еще она легко читается и по объему чуть больше 200 страниц.

Купить можно у МИФ.

Еще дочитала "Искусство объяснять" и "Impact Mapping",  и там есть, о чем написать - затягиваю, но скоро будет.

Принципы Пальчинского
#терминология

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

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

В книге Impact Mapping автор немного переформулировал эти принципы применительно к IT, хотя суть осталась та же:
- Ищите свежие идеи и тестируйте нестандартные подходы
- Новые идеи должны тестироваться в небольшом масштабе, чтобы неудачи не превращались в катастрофы
- Стремитесь получать обратную связь и учитесь на своих ошибках.

5 почему - метод для нахождения корня проблемы

Сакичи Тойода, основатель компании Тойота, для принятия решений пользовался методом "5 почему", который стал широко известен и часто упоминается в методологии Lean - бережливом производстве (потому что бережливое производство - это методология, которая началась с опыта  Тойота).

Приходит к вам, например, менеджер, и говорит - клиент отказывается платить за рекламные листовки. Вы начинаете выяснять и все, что вам нужно - задать 5 раз "почему?":

— Почему? Листовки были на день позже мероприятия, на котором они должны были раздаваться
— Почему? Листовки печатались дольше, чем обычно
— Почему? Закончилась краска в принтере
— Почему? Расход краски для этого заказа был слишком большой, а быстро найти краску для принтера не смогли
— Почему? На нашем складе не было краски для принтера (потратили все на предыдущий заказ)

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

Ну и на самом деле "почему" может быть не 5, а больше, но обычно больше не требуется. Использовать можно в любой ситуации - в том числе, когда кто-то убеждает вас сделать какую-то доработку, а вы уверены, что она проблему не решит.

Сделала для Нетологии подборку каналов про аналитику и продукт - советую посмотреть)

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

В общем, смотрите и читайте: https://netology.ru/blog/telegram-dlya-prodaktov

Качество спецификации
#аналитика

В "Deadline" описана очень простая истина: спецификация системы состоит из двух частей - описание входящих и выходящих параметров, и внутренняя логика.

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

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

Один из огромных провалов в управлении проектами - Денверский аэропорт

В 1988 году в Денвере решили открыть аэропорт. Открытие запланировали 31 октября 1993 года, и к этому сроку было готово все, кроме одной части проекта - системы обработки багажа. Потери от задержки проекта составили около полумиллиарда долларов (аэропорт открылся частично только в 1995 году).

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

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

А слова "система автоматической обработки багажа ДМА" с тех пор стали символом некомпетентого управления проектами.

Временный пост:

Друзья, у меня есть отличный Senior PHP-разработчик/системный архитектор в поиске работы. Может тимлидить, выстраивать процессы, строить системы с нуля. Применяет DDD, ведет блог о программировании -  https://medium.com/@wrong.about/.  Город - Москва (может рассмотреть удаленку)

Вместе работали - знаю, кого рекомендую :)
Если интересно, напишите мне - @shenzzzi

​​Специалисты компании Gartner, думая о том, как создавать новые продукты, соединили три подхода: дизайн-мышление — для создания эффективных идей, бережливое производство — для создания бизнес-моделей и гибкие методологии — для разработки.
Немного подробнее тут: http://bpmcafe.ru/blog/398807

Статью написала Юля Билинкис, преподаватель в НИУ ВШЭ и тоже автор канала для аналитиков — https://t.me/bpmcafe

Что такое TDD и DDD
#терминология

После поста выше про разработчика мне стали приходить в личку сообщения на тему "вы, наверно, опечатались, не DDD, а TDD". Так вот, я не опечаталась - я написала именно то, что хотела.

А теперь разбираемся, что же такое TDD и DDD:

TDD (Test Driven Development) относится к подходам к разработке. Смысл его в том, что сначала пишется тест, покрывающий какой-то один (самый простой) пользовательский сценарий, и только затем пишется код, который проверяется по написанному ранее тесту. И так, постепенно наращивая сложность сценариев, разрабатывается весь функционал.  При таком подходе разработчики фокусируются на необходимом функционале, а не функционале "на будущее", ведь главной задачей становится прохождение ранее написанного теста, а также перестают бояться вносить правки в систему, потому что с тестами это делать безопасно: их предполагается запускать примерно каждые несколько минут, и если правка сломала код, то тесты об этом незамедлительно сообщат.

DDD (Domain Driven Design) относится к архитектуре системы, это предметно-ориентированное проектирование. При таком подходе разработчик должен хорошо понимать предметную область бизнеса и бизнес-процессы в самой компании, чтобы выстроить архитектуру системы в соответствии с ними. В этом главный плюс DDD: программирование — это перенос законов бизнеса в код. Если человек не понимает законов и правил бизнеса, то это отразится в коде и с этим кодом можно будет работать при создании какой-то домашней страницы, но в сложных системах он быстро станет неподдерживаемым.

Про риски в управлении проектами

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

Идеальная (1% вероятности сдачи) — если все пройдет гладко,
Эластичная (50%) — проект действительно может быть сдан,
Наиболее вероятная (75%) — вероятность сдачи проекта большая,
Крайняя (99%) — когда на проект обрушились все риски и задержки, и позже этой даты он точно сдан быть не может.

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

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

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

​​Вот как выглядят эти два графика (давайте примем гистограмму за график - просто представьте, что по ней идет усредняющая линия): первый просто показывает, какая вероятность того, что проект будет готов к этому сроку или раньше, а второй показывает вероятность, что проект будет сдан именно в этот срок.
Эти типы графиков называются "кумулятивный" и "дифференциальный" соответственно.

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

Про повышение доверия в команде

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

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

Отнеслись бы вы к этой идее с энтузиазмом?
1 — Обрадовался бы возможности лучше узнать коллег и поддержал бы
2 — Все равно/сам бы не особо откровенничал, но коллег бы послушал
3 — Посчитал бы затею откровенно глупой и ненужной, рассказывать что-то вряд ли бы стал.

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

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

Конфликты, полезные для компании

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

Менять эту ситуацию надо именно руководителю.

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

Во-вторых, разрешите конфликтам происходить. Когда кто-то начинает, даже робко, высказывать свое мнение, можно вмешаться и подбодрить спорщика, что он все делает правильно. Это называется "разрешение в реальном времени", и помогает, не уходя с темы, сбавить неловкость.

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

И помните: больше доверия - больше "идеальных" конфликтов - еще больше доверия.