Comments 8
Часть принципов, которые вы описали, я также использую в своей работе. Они очень помогают.
Принцип пустого ящика. Вся поступающая информация при обработке делится на 4 направления:
• Обработанное, т.е. ничего делать не нужно. Просто перемещаем в папку Обработанное в Outlook.
• Задача, т.е. создаётся задача в jira, trello и т.д.
• Встреча, т.е. намечается встреча в outlook.
• Справочник, т.е. полезная информация, которая заносится в справочник или Wiki, и которая может нам пригодиться.
Правило Парето. 20% задач дают 80% результата. Не надо делать всю работу, а надо сосредотачиваться на том, что позволяет двигать нас ближе к цели. Некоторые задачи с низким приоритетом не будут сделаны никогда – это нормально.
Принцип разделения больших задач на более мелкие. Декомпозиция. Кушаем слона по кусочкам.
Вычеркиваем сделанные задачи, а не удаляем. Мозгу будет приятно видеть, как мы хорошо потрудились, смотря за зачёркнутые (выполненные) задачи.
Выгружаем всю информацию из головы на бумагу. Это уменьшает тревогу, экономит мыслетопливо и позволяет спокойно спать.
Для того, чтобы справиться с большими объёмами работы есть несколько простых правил: Оптимизируй (стандартизируй, затем автоматизируй), Делегируй, Приоритизируй, Откажись в всякой фигни.
В тему поста.
Делать меньше, но важного — ключ к успеху, потому что решение важных проблем снижает нагрузку на вас и позволяет приступить к менее важным проблемам.
В одном предложении два противоречия:
1) Делать меньше, но важного, автоматически исключает решение менее важных проблем — вы всегда загружены решением только важных проблем.
2) Решение важных проблем не снижает нагрузку, а лишь изменяет приоритеты. Вы всё равно остаетесь загруженными решением важных проблем.
Практически во всех рекомендациях по time management фигурирует совет сосредоточиться на главном, закрыв глаза на второстепенное.
Видимо, именно по этой причине баги, о которых пользователи сообщают производителю, остаются неисправленными в течение многих лет, а то и пожизненно.
"Мелочи не имеют значения — они решают всё!" (с)
Поэтому более правильной стратегией представляется комбинированный подход с гранулярной расстановкой приоритетов.
На примере разработки ПО: предположим, есть бэклог с сотней багов. Предположим, мы ставим задачу на следующий спринт пофиксить десять из них.
Если действовать по-вашему, то будут исправлены 10 багов с высшим приоритетом (Р1).
Если действовать по-моему, то будут исправлены 7 багов Р1, 2 бага Р2 и 1 баг Р3.
В первом случае мы получаем "сырой" продукт, во втором лишь "сыроватый".
Понятно, что успех продукта будет выше у того производителя, который принимает во внимание обратную связь от пользователей, а не у того, кто практически полностью игнорирует её (привет, Самсунг).
В одном предложении два противоречия:1) Делать меньше, но важного, автоматически исключает решение менее важных проблем — вы всегда загружены решением только важных проблем.2) Решение важных проблем не снижает нагрузку, а лишь изменяет приоритеты. Вы всё равно остаетесь загруженными решением важных проблем.
Противоречий нет.
Когда находишься в состоянии, где у тебя куча острых проблем со всех сторон - они все жрут силы и время.
Решая самые важные из них, вы освобождаете себе энергию, с которой вы уже можете приступить к решению менее острых и важных. Более того, сосредоточившись на них, отбросив всё, что можно - вы решаете эти самые острые и важные проблемы эффективнее - а значит, быстрее выходите из состояния шторма.
Ваш пример с бэклогом во-первых, не про критическую ситуацию, а про обычную работу. А во-вторых - у вас странная трактовка "важности" и "сырости".
> Если действовать по-моему, то будут исправлены 7 багов Р1, 2 бага Р2 и 1 баг Р3.
И этот вариант хуже. Почему у багов P3 меньше приоритет? Потому что они влияют на меньшее число пользователей и при этом менее критичные. А значит - да, надо фиксить баги с высшим приоритетом.
Если баг долго не решается - его приоритет может вырасти и стать P1 или P2. Если же он лежит в P3, но при этом сделать его важнее, чем P1 - значит у вас бэклог с плохо проставленными приоритетами, либо же просто не обновлёнными.
> Понятно, что успех продукта будет выше у того производителя, который принимает во внимание обратную связь от пользователей, а не у того, кто практически полностью игнорирует её
Успех будет выше у того продукта, который ориентируется на количество и важность этой обратной связи. Или у того, который будет разумно расходовать деньги, грамотно балансируя между идеальностью и нужностью рынку
Решая самые важные из них, вы освобождаете себе энергию, с которой вы уже можете приступить к решению менее острых и важных.
Не убедили. Важные проблемы были, есть и будут всегда. Это значит, что времени на решение менее важных проблем не будет никогда.
То же с багами. Из-за постоянного наличия Р1 и Р2 никогда не будет времени для фикса Р3.
Если баг долго не решается — его приоритет может вырасти
Не может. Потому что приоритет бага определяется не тем, сколько времени он лежит в бэклоге, а тем, что "они влияют на меньшее число пользователей и при этом менее критичные" (ваши же слова, снова сами себе противоречите).
Успех будет выше у того продукта, который ориентируется на количество и важность этой обратной связи.
Именно так. И, похоже, игнорирование именно этого простого правила привело к слиянию поглощению компании Uzum компанией Click.
В статье есть полезные рекомендации, но основной поcыл — если вы устаете от работы, меньше работайте.
Это действительно помогает восстановиться. Но к успеху продукта и компании не ведет.
Видимо, именно желание поменьше напрягаться объясняет представление вашей компании в интернете всего одной страницей лендинга, на которой отсутствует даже копирайт с датой.
А две ошибки в тексте одного короткого абзаца, благодаря желанию "балансировать между идеальностью и нужностью рынку", не будут исправлены никогда:
Если мне далось показать и доказать вам и читателям, что принцип good enough — это зло, то я рад; значит, не зря потратил время.
Если не удалось, то нет смысла продолжать дискутировать. Я всё равно останусь верен принципу The Best Or Nothing.
Потому что, как Вы устали от работы, так и я устал от бесконечной забагованности современных продуктов.
Но еще больше — от категорического нежелания производителей работать над исправлением ошибок по обращениям клиентов.
Так а зачем решать менее важнве проблемы первее более важных?
У меня работа команды заблокирована - пойду обсужу бэклог на сдедующий квартал с продактом.
У меня проект не собирается - пойду текст на кнопке поправлю.
У меня человек собрался увольняться - пойду помогу соседней команде с багфиксингом.
Где тут логика?
Бывает иногда такое, что кому-то нужна ваша помощь в пустяковом деле, он её ждёт, но вы всегда заняты "более важными делами".
Тут одно из двух - возможно, действительно другие дела более важны, и тогда делать надо их. Либо это дело только кажется неважным, но на самом деле важное, и тогда ему тоже стоит уделить внимание.
Когда становишься лидом, довольно быстро понимаешь, что чтобы помочь всем и сделать всё красиво, нужно бесконечное количество времени. У вас его нет, значит вы гарантированно кому-то откажете в помощи и никогда не решите их вопрос. Физику не обманешь. От того, что вы вставите какое-то дело между другими двумя, вы не сделаете эти три дела за время двух. Просто несделанным останется не это дело, а какое-то другое.
Что бы вы выбрали - чтобы у вас текст в меню был с ошибкой, или чтобы меню не отображалось вовсе?
(del — комментарий не в том посте)
Как не развалить команду, когда тебе фигово