Демотивируй правильно! / Егор Бугаенко (Zerocracy)
Vložit
- čas přidán 13. 04. 2020
- Приглашаем на конференцию TeamLead Conf 2024, которая пройдет 27 и 28 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: vk.cc/cuyJ0A
---------
При поддержке AvitoTech мы впервые публикуем все видео с Product Fest 2019 в открытый доступ. Учитесь, вдохновляйтесь и перенимайте лучшие практики у спикеров, не выходя из дома.
--------
Календарь конференций - ontico.ru
--------
Product Fest 2019
Тезисы и презентация:
productfest.ru/moscow/2019/ab...
Задерживаешь зарплату? Ставишь неясные задачи? Часто меняешь проекты? Увольняешь талантливых и оставляешь подхалимов? Обещаешь бонусы и не платишь? Этого недостаточно.
Для правильной демотивации тебе нужны техники более высокого порядка. С ними и познакомимся поближе. Не пропусти.
--------
Нашли ошибку в видео? Пишите нам на support@ontico.ru
про адвоката-обвинителя на 47 минуте прям в точку. отличный доклад. Спасибо, Егор!
Очень понравился доклад
Одни милые люди на стороне заказчика строят из себя специалистов и готовят, якобы, грамотные требования. Другие милые люди на стороне исполнителя никогда не спорят - Клиент Всегда Прав - я рьяно берут под козырёк. Результат работы удивляет и тех и других, но никто никого не подставляет, бюджет накидывается и работа идёт дальше.
На том и стоим)
По моему опыту разработчики должны проверять и дополнять работу продакта и аналитика, иначе пишется код формально корректный, но плохо работающий на практике. Другими словами, разработчик - тоже продакт, и тоже аналитик.
Для некоторых видов продуктов лучше пойти ещё дальше и сказать, что нет или почти нет отдельных людей-продактов и людей-аналитиков, а разработчики берут на себя эти роли почти полностью. Всё это, конечно, возможно, если вы готовы нанимать разработчиков соответствующего уровня.
Разумная мысль. Если разработчик хочет максимально чётких требований, расписанных в заданном формате, то возникает пара вопросов:
1. В чём задача программиста? Просто переводить текст с человеческого на заданный ЯП? Зачем тогда всякие синьйоры - любой джун так сможет 🤷🏼♂️
2. Что мешает заменить такого программиста программой? Требования структурированные и чёткие ;пишешь интерпретатор и вуаля - работающий код готов 🙂
нет, не разумная. на каждом уровне свой большой объем работы, менеджер от которого приходит, как выразился Егор, мусор, плохо выполняет свою часть работы которая просто ложится в команде на того, кому не все равно и кто тянет проект. а про то, что между джуном и синьором нет никакой разницы в том как технически будет реализована задача это даже не смешно(
Зачем тогда нужны аналитики?)
@@tape_hape5427 зарплату получать и выебываться в комментариях что программисты просто код хотят писать
ПМ-ы рисуют домик с клиентом. Потом ПМ-ма дрючит директор за недостроенный домик, ну а ПМ капает на мозг программисту.
Господи сколько дополнительного времени уходит на эту «войну» с требованиями и как легко под борьбой за качеством скрывать желание работать помедленнее
Настоящее качество рождается из совместного желания делать качественно
Желание не материально. Проявляйте его в документах)
Почему актёр всегда за пределами системы? А если бизнес-задача выполняется по таймеру или другому внутреннему событию?
Сначала мне показалось, что у человека полная каша в голове. Потом некоторые моменты показались здравыми (трассировка требований, конкретика, фокус на том, что надо сделать, а не как технически). А потом встало все на свои места, выборка у докладчика небольная, ТЗ пишется больше для защиты, такая придирчивость оправдана (хотя человека жалко, нелегко в таких условиях работать). У ТЗ есть три основные сферы применения: получить оценку затрат, рисков и т д, убедиться, что делается именно то, что решает проблему, и собственно подстраховаться от заказчиков/исполнителей. Тут, очевидно, третий случай - самый неблагодарный. Серьезно, если приходится так работать, это выматывает. Именно такие ТЗ и получаются - с одной стороны, максимально размытые, с другой программисты максимально въедливые. Ситуация you win - I lose. Но многие работают в другой парадигме, когда и PM/PO, и тех лид/менеджер хотят максимальную пользу за фиксированное время, и тогда наступает эра разговора - вот примерно как в первом примере. I believe - потому что хорошо бы, но не за все деньги мира. Послушаю, что вы скажите, и мы договоримся на оптимальном варианте. А еще версии вот тут в URL, у нашего соседнего продукта так, вдруг тебе пригодится. Но вообще я тебе доверяю, скажи, что тут лучше будет. Нормальное такое начало разговора с архитектом или лидом, приглашение к обсуждению. Ок, это не будет в документации, но может спецификацию тогда вообще технарь напишет. Это так, к слову, показать другой тип взаимоотношений.
С таким уровнем занудства докладчик не ту специализацию в IT выбрал. И, судя по всему, ему по жизни не везло с продактами (. Ну и продактам с ним тоже не фартило )
Худший докладчик на этом канале)
3 пункт - повторюсь .. просто переведи на русский язык .. и все станет понятно .. не надо английский язык транскриптировать !!! не надо !!! надо переводить на РУССКИЕ слова и понятия !!!
💯