Доклад на конференции - какую проблему решает?

Сегодня ехала я на работу в метро, читала себе Карла Вигерса и параллельно размышляла на тему своего предстоящего доклада на Auto Confetqa, на тему будущей Fun Confetqa... И пришла я к мысли, что хороший доклад должен содержать ответ на вопрос - а какую проблему я решаю?

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

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

Вот например. Рассказал человек о том, как у них все круто на проекте. Ну ок, а дальше что? А как это к нам применить? И главный вопрос - а нужно ли? Если да, то зачем? Как настоящие тестировщики, мы придираемся к ТЗ или, в данном случае - к аннотации

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

И это кажется таким естественным! Само собой разумеющимся! А вот поди попробуй поставить процесс с нуля или внедрить что-то новое.

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

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

Так как им постоянно звонили пользователи, у которых что-то не работало, потому что карточка была не в том статусе. Они спрашивали, что им делать, а тех поддержка спрашивала у нас, какие статусы после каких идут. Это, конечно, можно было и без майнд-карты нарисовать, но мне очень хотелось попробовать. Так что я нарисовала карту проекта, отдельно выделив на ней статусы. Полезно было, да! Заодно и продукт изучила, перед уходом то)))

А теперь, пытаясь внедрить карты на новом месте, я столкнулась с непониманием того, "а как?". А что вообще в них должно быть? Ладно, взяли, попробовали, действия, переменные, все по правильному. Не срослось. Почему? Ну, ничего нового не узнали... Я понимаю, конечно, что не все техники приносят плоды в первый час, но в их эффективность должен верить хотя бы сам инициатор. Иначе она постепенно испаряется...

А потом меня еще и Таня добила вопросом - а зачем тебе карты? Может, они не нужны?
Ну как это зачем? Я знаю, знаю зачем! Я хочу, чтобы висела на стене такая красивая карта на А3, а рядом еще одна, и еще. И чтобы посмотрел на карту, и сразу понял, чем эти проекты друг от друга отличаются - а значит, на что обращать более пристальное внимание.

Тогда какого хрена ты на "внедрении" рисовала детализацию функций? Это такой риторический вопрос к самой себе... Вот вроде знаю чего хочу, а реализовать не так то просто...

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

А вот если нету этого, то так сложно начать. А главное - сформулировать проблему. А то и сам начинаешь сомневаться, надо ли оно?

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

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

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

PS - А вот про карты я знаю, кому задавать вопросы. Ну, Таня, берегись!