Привет. Со старым Новым годом. А давай сегодня воодушевлённо будем строить планы на будущий год?
https://youtu.be/yUPLPBkWme4

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

Agile головного мозга 🤯
https://t.me/agilehb

Об особенностях оценок задач

Есть 2 разные сущности, которые хранят в тикет-системах: эпики (они же user story) и тикеты (они же задачи). При этом программисты (QA, дизайнеры...) не любят оценивать вообще всё, а менеджеры наоборот стремятся оценить каждый вдох. Чтобы понять где правда, нужно понять, для кого создаются все эти сущности. Давайте отдадим эпики менеджерам, а тикеты - работягам. Для первых будем играть в покеры при оценке и всячески вытаскивать блокеры, а вторым запретим оценку и дадим указание делить задачи до тех пор, пока не появится ощущение, что задачу можно выполнить за час.

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

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

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

Почему задачи должны быть час-два (край 4 часа)?

Раз. Чем меньше оценка, тем меньше шансов ошибиться
Два. Каждый день мы тратим на коммуникации не меньше часа (дейли, уточнение требований, коммуникации по процессам...), плюс всевозможные ревю, передача задач, разбор почты и/или дашбордов и/или тикетов...
Три. Максим Дорофеев называет это "мыслетопливо". Коротко - это способность решать сложные задачи и принимать решения. Эта способность в среднем составляет 4 часа в день на человека
Четыре. Если мы ошибочно оценили задачу в 2 часа, то об ошибке мы узнаем через 2 часа крайний срок. Если оценим в 16 часов, то можно тешить себя надеждой до истечения срока. Лучше обосраться раньше и быстро принять меры, чем потом хвататься за голову
Пять. Менеджер более наглядно будет видеть выгорание бэклога
Шесть (еще не надоело?). Нейробиологи говорят, что человеку жизненно важно каждый день побеждать. Если вы на протяжении долгого времени не закрываете задачи, то не видите достижений и мотивация падает

Сегодня в чате так смачно про еду заговорили. Надо продожить. Прям на стриме. Жду именно тебя, приходи и расскажи что-нибудь.
https://youtu.be/5QT-sARxi8I

SPA это не от хорошей жизни. Почему все забыли о тонких клиентах. Го устроим срачик. Быстрее приходи по ссылке, пока стрим еще идёт!
https://youtu.be/IsKkU2hVyiw

Что такое продуктовый подход и нахера он нужен. Сегодня будем разбираться
https://youtu.be/wWgrbAETcKE

Превед
Сегодня будет бомбёжка по поводу того, что выбрать любое оборудование - это больно, дорого и контрпродуктивно
https://youtu.be/JJhYO2V8Do4

Всех на прошедшей неделе бомбануло с одной нелепой социалки. Пойдём обсудим, почему это тупо
https://youtu.be/SdH8jIA4CQk

Продолжаем тут
https://youtu.be/oBpP9DUz_4Y

Запоздалый стрим о взгляде на запад и восток
https://youtu.be/G1YU3XdWDIs

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

Почему важно ставить цели ОКР: потому что мы ставим ориентир. В духе "купить херню для дома". И решаем, что лучший способ достичь цели - доехать до Икеи и там это купить. Но при этом мы не прописываем маршрут на протяжении всей дороги: где как проехать, где в на какую передачу переключиться. При этом мы по пути можем изменить маршрут или завернуть в другой мебельный магазин. А то и вовсе в Леруа Мерлен и там купить, все, что нам нужно. Т.е наша цель это просто ориентир "купить какую-то херню. Например, в Икее".

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

Но, если мы рассматриваем процесс достижения цели не как поездку на машине, а как полет на ракете, то это беда. Полет на ракете полностью зависит от старта. Любая ошибка в планировании чревата катастрофой. И если катастрофа началась, то все силы кидаются на минимизацию потерь (причём по заранее разработанному плану), ни о каком достижении целей речи не идёт. Большинство бизнесов (и стартапов, о ужас) не смотрят на бизнес, как на поездку на машине. Они расценивают бизнес, как полет на ракете: долгая тщательная проработка строгого пошагового плана действий. И после начала реализации этого плана будут стараться его придерживаться, что может оказаться губительно для бизнеса в случае даже мельчайшей ошибки.

Т.е цели должны быть простыми, понятными и не содержащими ненужных деталей. Иначе возникнет соблазн принять детали за инструкцию к действию. Нужно помнить, что для достижения целей редко есть только один путь. А планировать нужно “от перекрёстка, до перекрёстка”. Добравшись до контрольной точки вы оцените обстановку с оглядкой на пройденный путь и спланируете следующий короткий отрезок пути. Планы нужны по ситуации и там, где они уместны

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

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

Мамкин стартапер уже в эфире
https://youtu.be/-mjvhNy58Tk

США закручивает гайки ютуберам. Обсуждаем конец эпохи дикого запада в сети
https://youtu.be/vaIcF_0wdu8

Вечер вопросов на ваши ответы объявляю открытым
https://youtu.be/XoyFTCxGSqs

Хозяйке на заметку: если вы хотите купить ноут для пользования с линуксом, но не хотите напороться на вероятность того, что что-то пойдёт "не так", то можно просто проверить, сертифицирован ли данный девайс под Ubuntu.
https://certification.ubuntu.com/desktop

Это слишком замечательно, чтобы не протащить это по всем каналам)

Попалась забавная заметка. Она больше кодерская, но интересно будет почитать всем, кто не занимается кодингом. Взгляд на проблему с точки зрения "а сколько это нам стоит? А получаем ли мы выгоду пропорционально?". Чтобы прям совсем пуканы подпалить кодерам, можно попросить подсчитать, сколько стоит обслуживание тестов)
Не подумайте, я всегда за тесты и код ревю, но всегда должен быть разумный предел, плюс нужно держать в голове цену обслуживания всего этого

Собсно семя холивара воть:
https://git.io/codereview_analysis