26 заметок с тегом

Полезное

Черная книга Скрам

Рекомендую новую книгу Ивана Селиховкина «Черная книга скрам»

Эта книга квинтэссенция и моей боли как управленца и причина по которой Скрам не использую ни в одном из своих проектов.

В целом это подтверждается и самой аджайловой индустрией: посмотрите сколько процессов в проектном управлении организации по SAFe бегут по Канбан методу, и сколько отведено под scrum (https://www.agilest.org/scaled-agile/safe-framework/)

Подсказка: только один, да и тот опционально

http://scrumblackbook.pmlead.ru

Спасибо, Иван!

2018   Scrum   Книги   Полезное

Говори как менеджер (урок английского)

  1. find out what’s wrong —> identify the problem
  2. fix the problem —> resolve the issues
  3. give people confidence —> motivate my employees
  4. give clients my attention —> focus on our clients
  5. spend as little as possible —> minimise our expenses
  6. make as much money as possible —> maximise our earrings
  7. get more work —> generate more business
  8. use the new ideas —> implement the strategies

identify risks, person, reasons, ways
resolve the situation, crisis, disagreements, tension
motivate the staff, team, kids, spouse
generate more sales, revenue, interest, enthusiasm
focus on priorities, goals, studies, health
minimize costs, time, noise
maximise profit, efficiency, grades, investments
implement the changes, policies, safety rules, suggestions

Продолжение уроков: https://www.engvid.com/speak-like-a-manager-verbs-1/

2018   Обучение   Полезное

Как косячить

Илью зовут на вечеринку в 20:00. Чтобы успеть, Илья должен выйти с работы в 19:00. Попросили по дороге заехать за пиццей. «Успею», — думает Илья.

19:00 Илья ковыряется на работе.

19:30 Илья выходит с работы. В городе пробки, приедет он с опозданием на час-полтора. Но Илья никому не звонит, потому что не хочет краснеть перед друзьями.

19:35 «Да и потом, это ж вечеринка, никто не приходит вовремя, да и все знают, что в городе пробки».

19:40 «И они могли бы и раньше меня позвать, я бы как-то лучше распланировал свой день».

19:50 Илье пишут друзья: «Ну что, ты где?». Илья видит уведомления, но не открывает их, чтобы не было галочки «прочитано». Неудобно, что он так поздно выехал.

20:10 Друзья звонят. Илья не берет трубку, зная, что придется краснеть.

20:30 Илья придумывает шикарную отмазку и перезванивает: «Только вышел с совета директоров, эти дебилы никак не отпускали, еле вырвался. Извините, всё, сейчас прыгну в машину и приеду к вам».

20:45 Илья заходит за пиццей. Понимая, что провинился, он покупает раза в три больше, чем его просили.

21:30 Илья появляется на пороге. До него уже успели заказать пиццу и ее только что привезли. Несмотря на полные пакеты и дикие извинения, Илью принимают холодно.

00:00 Большая часть закусок и пиццы остыла и высохла до того, как к ней успели притронуться.

Что в итоге. Илья потратил кучу денег, подпортил отношения и из-за него высохло четыре невинные пиццы.

Или нет, погодите. Всё было не так.

19:00 Илья ковыряется на работе.

19:30 Илья выходит с работы. В городе пробки. Илья переборол стыд и звонит друзьям: «Ребзя, я опаздываю, извините, буду во столько-то. Могу рвануть на метро, но тогда не смогу заехать за пиццей». Друзья в один голос: «Ой, да плевать на пиццу, приезжай скорее. Пиццу закажем».

20:10 Илья выходит из метро и звонит друзьям: «Тут возле выхода есть универмаг, у них должна быть замороженная пицца, взять?» Оказывается, пиццу уже заказали, но нужно докупить выпивки. «И чипсов!» «И сладенького!» «И на завтрак ничего нет!» «И туалетной бумаги десять рулонов!»

Ну, бывает.

20:30 Илья появляется на пороге с пакетами. Его встречают, как героя. Как раз все в сборе.

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

Замените вечеринку на статью, друзей на клиентов, пиццу на интервью с экспертом, пробку на творческий кризис, а «восемь вечера» на «дедлайн» — получится редакторский проект. Замените на дизайн в соответствии с брендбуком — будет проект с дизайнером. Задача по работе мало чем отличается от задачи для друзей.

Мораль

Как грамотно косячить на проекте:

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

Приходить с решением. Не просто «опаздываю», а «опаздываю, предлагаю заказать пиццу по телефону».

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

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

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

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

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

Совсем мораль

Если коротко, то правила на самом деле три:
1. Общаться, а не молчать. Все проекты ломаются тогда, когда люди начинают делать каждый свое, не не держа друг друга в курсе. Видите проблему, даже со своей стороны, — сообщайте о ней. Вместе с клиентом вы придумаете, как ее решить.

2. Помогать, а не увольняться. У многих, когда они косячат, включается комплекс отличника: «как же так, я что-то сделал плохо, я плохой, я недостойный, сейчас меня уволят». Это ерунда. Клиенту наплевать, хороший вы или плохой. Ему надо решить задачу, и ваш косяк — просто обстоятельство.

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

3. Не быть бараном. Накосячили — признайте, не оправдывайтесь. И чините, а не ждите, что всё исправят за вас.

Источник: Ильяхов

Полезное по теме
Начитаются кемпами и травят леску за гаражами

2018   Люди   Полезное   Управление проектами

Про скорость разработки в Канбан

В августе 2016 года на одном из проектов установили ограничение Work In Progress равное количеству девелоперов работающим над проектом. Т. е. если кто-то заболевал или уходил в отпуск, ограничение Work In Progress уменьшалось на единицу. При добавлении разработчиков, увеличивалось на единицу.

На скриншоте Control Chart в Jira и эффект от внедрения данной практики:

Rolling avarage дней между «взято в разработку» и «готово к релизу» (конкретно на этом проекте даже выкачено на продакшен) снизилось с 7.4 дней до 2.7 дней.

То есть бизнес стал получать свою функциональность в два раза быстрее.

Недавно проводил мастер-класс новой проектной команде по Канбану и WIP:

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

Частая картина в девелоперских командах:

  1. Программист взял Задачу 1 в разработку
  2. Отправил Задачу 1 на тестирование
  3. Тестер приступил к тестированию через 5 часов
  4. Программист пока взял Задачу 2
  5. Задача 1 вернулась с багом
  6. Программист решает закончить Задачу 2
  7. Через 3 часа программист отправляет Задачу 2 на тестирование
  8. Программист возвращается к доработке Задачи 1
  9. Через час исправляет баг и отправляет Задачу 1 на тестирование
  10. Через 2 часа Тестировщик приступает к тестированию Задачи 1
  11. Задача 1 отправляется в релиз

Итого время простоя задачи
на пункте 3: 5 часов
на пункте 7: 3 часа
на пункте 10: 2 часа

Проблемы бесконтрольного набора задач:

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

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

Так вот, в моих командах, процесс устроен следующим образом:

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

    1. минимальное время на реализацию задач
    2. минимальное количество задач погрязших в болоте доработок
    3. у программистов и тестировщиков есть время на саморазвитие
    4. бизнес подразделение довольно: новая функциональность начинает приносить деньги сразу же, а не «через 2 недели, когда будет релиз»

    + Полезное из переписки на facebook:

    2017   kanban   Полезное   Управление проектами

    Про внимание к деталям

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

    2017   Полезное   Программирование

    Самое удивительное из WMC 2017

    Иду я между рядами всяких технологических стартапов, а там паренек одиноко стоит грустит с  фигурками отпечатанными на 3d принтере. Чего, говорю, делаете? Вот говорит берем оригинальные фигурки, сканируем смартфоном и потом можем их напечатать, например.

    Достает обычную сони иксперию, запускает их какую-то аппу, которая в «панорамном» режиме снимает селфи. Потом приложение 5 минут думает и выдает вот это:

    https://www.astrivis.com/scan3d/viewer/xfS04yh59mdRTcjdK2gtBw== (можно покрутить мышкой)

    2017   Полезное   Удивительное

    Инструментов второй пост

    Созрел пост об используемых инструментах. В этот раз не о программах, а об организации.

    1. Trello вместо Wunderlist

    Списки дел неудобны т. к. не отражают прогресс выполнения
    В трело у меня доска на 5 колонок:
    куча | сделать | в работе | жду ответ | сделано

    Пробовал сделать шкалу прогресса выполнения 20% 40% 60% — как-то не зашло. Слишком много ресурса отбирает оценка готовности. Зачет/незачет проще и быстрее.

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

    2. Список коммуникаций за день

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

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

    3. Матрица принятия решений, когда все не так однозначно

    Что будет если ДА Что не будет если ДА
    Что будет если НЕТ Что не будет если НЕТ

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

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

    4. Диаграммы последовательности

    Это мой любимый инструмент уже много лет

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

    5. Загрузка правого полушария

    Когда на работе слишком много логики и начинает «клинить»: теряется концентрация и накапливается усталость, лучший выход — загрузить черепушку чем-то другим.
    Мне помогают музыкальные инструменты и дочкины раскраски :-D

    Ссылки:

    2017   Полезное   Про себя

    Как создать групповой чат в мобильной версии Skype?

    Оказывается, чтобы создать групповой чат или звонок в мобильной версии Skype в iOS нужно открыть чат с собеседником, тапнуть на имя собеседника в верхней части экрана, и в выпавшем меню нажать «Добавить участников».

    Вот тебе и дизайн интерфейсов.

    2016   Полезное

    О противопоставлении project-ов и product-ов на примере бабушек

    © Иван Селиховкин
    https://www.facebook.com/ivan.selikhovkin/posts/10207032631638700

    Давешнее. Давайте объясню что думаю о противопоставлении project-ов и product-ов на примере бабушек?

    У вас есть ребенок. Его надо регулярно укладывать спать. Ваша задача — чтобы он научился это делать самостоятельно (в идеале — оказался в кроватке, похлопал глазками и задремал).
    А у ребенка — бабушка. Любящая и самоотверженная. Она помогает.
    Вы решаете делегировать одно или два “укладывания” — ей.

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

    Когда бабушка — иначе. У нее на первом месте — лишь бы малыш не рыдал (она его любит, она не так уж много проводит с ним времени, поэтому укачивать на руках — лично ей не особо и трудно). Кроме того бабушка — боится, что если дитя будет часто плакать в ее “дежурство” вы перестанете ей доверять.

    В итоге из 6-7 укладываний — одно или два за бабушкой, которая подхватывает, баюкает малыша на каждый всхлип. Ребенок существо смышленое — быстро привыкает и скоро на меньшее уже не согласен.

    Если представить, что я говорил о бизнесе, то бабушка — это project manager. Мотивированный, добросовестный, и по формальным результатам у нее все не плохо (ребенок засыпает быстро). Но она делает не то что надо. Цели разные, своих бабушка достигает, вашим отчасти противоречит.

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

    Лет десять назад “лекарством” являлись KPI. Бабушке нужно было объяснить, что важно не укладывать быстро, а укладывать + не брать на ручки + не петь колыбельную (и растолковать почему это важно — ведь через год малыш станет неподъемным, а на колыбельные уже голоса не хватит). Работодатели объясняли “бабушкам” (рисовали сбалансированные показатели на уровне стратегии, спускали ниже, привязывали к выплате бонусов). Но менеджеры работали все равно по-своему (только теперь у них было одной заботой больше — скрыть как именно они “баюкают малыша”). Несовпадение целей одними только KPI-ми не лечится.

    Сейчас распространена уверенность — project не нужен, заведем product-a.

    И появляется бабушка-product manager. Ее ответственность не ближайший результат (уложить ребенка) а долгосрочный (обеспечить чтобы через пол года он спал сам). Или в случае с уроками — не проверять домашку, а обеспечить, чтобы он научился сам получать знания, поступил в ВУЗ и в конечном счете нашел работу мечты (своей мечты, не вашей).

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

    Вот только бабушке от этого не легче. Вы только что делегировали ей ответственность за мало понятный результат. Не каждая бабушка доживет (хотя дай ей бог здоровья) до выхода внука на работу (равно как и не каждый product в вашей компании дождется снискания своим детищем коммерческого успеха). Бабушке, порой, не ясно как измерять промежуточные успехи (сегодня внук делал домашку лучше, завтра хуже, а потом снова хорошо; из школы принес то двойку то пятерку — это что вообще значит, он приблизился к работе мечты или нет?)

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

    Для подобных проблем больше давным давно придумали термин “агентская проблема”. И абсолютного решения так и не нашли.

    А противопоставление product-ов и project-ов не имеет смысла.

    Project-ы и product-ы — две приходящие бабушки, противопоставляющие себя друг другу.

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

    2016   Полезное   Управление проектами

    Полезное почитать от Google

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

    https://rework.withgoogle.com

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

    1. проявляют себя как отличные наставники
    2. доверяют и дают возможность принимать какие-то самостоятельны решения своим людям
    3. интересуются судьбой каждого
    4. ориентированы на продукт и результат который они делают
    5. обладают отличными коммуникативными навыками
    6. помогают своим людям расти и развиваться
    7. имеют четкое представление о их проекте и будущем команды
    8. обладают отличными техническими компетенциями

    А вот следующий сайт я попал вообще случайно.

    https://www.thinkwithgoogle.com

    У меня на фейсбуке есть друг, у которого работа связана с фармакологией и он просто запостил ссылку на конференцию по Фарме, которую проводит Google .
    На сайте куча маркетинговой информации от гугла о самих себе и как они полезны для бизнеса, результаты исследований и полезные how-to.

    2016   Люди   Полезное
    Ранее Ctrl + ↓