Comments 6
Я просто оставлю эту GIF здесь
Очень странно блок-схема GTD смотрится в контексте работы разработчика. Большинство задач разработки не решаются за две минуты, делегировать некому, ставить в календарь бесполезно, потому что разработчик вообще мало своим рабочим временем распоряжается. Остается один вариант — сделать. Или сообщить руководителю, что сделать невозможно.
По сути и проблемы такой нет, никто не требует от разработчика сделать 50 действий одновременно.
По сути и проблемы такой нет, никто не требует от разработчика сделать 50 действий одновременно.
1. Большинство — не все.
2. Как правило, в командах существует специализация, хотя бы на уровне фронтенд-бэкенд.
3. Как правило, в командах существует разделение по квалификации и градации сеньор-джун означают не только уровень зарплаты, но и оперативное подчинение и одной из обязанностью сеньора является делегировать задачи или подзадачи джунам.
4. Частенько в разработке несколько проектов и их заказчики нередко имеют прямой выход на разработчиков.
5. Сделать или сообщить, что сделать невозможно — это да. Вопрос когда сделать.
2. Как правило, в командах существует специализация, хотя бы на уровне фронтенд-бэкенд.
3. Как правило, в командах существует разделение по квалификации и градации сеньор-джун означают не только уровень зарплаты, но и оперативное подчинение и одной из обязанностью сеньора является делегировать задачи или подзадачи джунам.
4. Частенько в разработке несколько проектов и их заказчики нередко имеют прямой выход на разработчиков.
5. Сделать или сообщить, что сделать невозможно — это да. Вопрос когда сделать.
Делаю так:
— Взять большую задачу и провести на декомпозицию на подзадачи. Получить work breakdown structure, короче.
— в отличие от проектной оценки, это WBS с «сырыми» элементами, т.е. они выбраны интуитивно, по ним не вынесено никакого окончательного решения. (Исследование по выводу окончательного решения делается не интуитвно, медленно, а значит само по себе является задачей, достойной фиксации)
— все элементы WBS становятся элементами папки «входящие»
— дальше работаем по алгоритму
Дальше уже дело техники. Например, оказывается что задача по WBS никак не влезает в дедлайн. Тогда мы расставляем приоритеты, и задачи с наиболее низкими приоритетами отправляем в папку «когда-нибудь потом».
Живой пример. Перед тобой поставили задачу сделать программу, которая хранит файлы на веб-сервисе, умеет их показывать, отображать список, итп. Типа Google Docs. Если стоит задача сделать через неделю демонстрацию для заказчика, и это очевидно нереально, то мы делаем WBS и некоторые элементы типа «хранение на веб-сервисе» просто отправляем в «когда-нибудь потом». Вместо этого в две строчки делаем хранение файлов на локальном жестком диске — в ходе демонстрации заказчик все равно никак не сможет проверить, действительно ли хранятся файлы в облаке или нет. Но после проведения показа нужно понимать, что задача еще не находится в статусе «выполнена», все отложенные элементы нужно тоже проверить, а возможно и отменить.
Дальше у таких отложенных элементов задач накапливается иерархия, которую нужно манагить. Например, задача «хранение на сервисе» бьется в дерево, часть задач там будет «на 2 минуты» которых можно делегировать аналитикам или тестировщикам.
Например: жуткий цейтнот, время до сдачи проекта пошло считаться на секунды, через 3 часа показ очередного этапа заказчику. Программисту нету времени на тестирование вообще. Он может зафигачить очередную кнопочку, код к ней, и не почти тестируя отправить ее на тестировщика. Пусть он потратит 5 минут на тестирование, работает ли вообще эта кнопочка, а ты за эти 5 минут напишешь еще несколько фичей. Или например, можно самому прочитать документацию чтобы понять ну… какая надпись должна быть вот на этой кнопочке. А можно делегировать это на аналитика, пусть он читает пока ты пишешь фичи, и вернется уже с конкретной строкой, которую нужно вписать в название кнопки.
Но так как человек не может эффективно работать по иерархии, такая последовательность мгновенных и отложенных действий все равно разлинеивается в список задач. А раз мы имеем список задач, то можем отправить его на вход GTD-алгоритму.
Мне кажется, что GTD подход это чуть ли не самое ценное из того, что позволяет не сойти с ума в декабре (когда как известно люди начинают работать с продуктивностью в тысячу раз больше обычной, чтобы успеть дофигачить все задачи) =) Если под рукой нету WBS'ов, их проекций в линейные списки-представления, и четкого алгоритма по тому как их парсить, мозг пытается включить интуицию и просто сгорает на перевычислении этих вещей на ходу.
— Взять большую задачу и провести на декомпозицию на подзадачи. Получить work breakdown structure, короче.
— в отличие от проектной оценки, это WBS с «сырыми» элементами, т.е. они выбраны интуитивно, по ним не вынесено никакого окончательного решения. (Исследование по выводу окончательного решения делается не интуитвно, медленно, а значит само по себе является задачей, достойной фиксации)
— все элементы WBS становятся элементами папки «входящие»
— дальше работаем по алгоритму
Дальше уже дело техники. Например, оказывается что задача по WBS никак не влезает в дедлайн. Тогда мы расставляем приоритеты, и задачи с наиболее низкими приоритетами отправляем в папку «когда-нибудь потом».
Живой пример. Перед тобой поставили задачу сделать программу, которая хранит файлы на веб-сервисе, умеет их показывать, отображать список, итп. Типа Google Docs. Если стоит задача сделать через неделю демонстрацию для заказчика, и это очевидно нереально, то мы делаем WBS и некоторые элементы типа «хранение на веб-сервисе» просто отправляем в «когда-нибудь потом». Вместо этого в две строчки делаем хранение файлов на локальном жестком диске — в ходе демонстрации заказчик все равно никак не сможет проверить, действительно ли хранятся файлы в облаке или нет. Но после проведения показа нужно понимать, что задача еще не находится в статусе «выполнена», все отложенные элементы нужно тоже проверить, а возможно и отменить.
Дальше у таких отложенных элементов задач накапливается иерархия, которую нужно манагить. Например, задача «хранение на сервисе» бьется в дерево, часть задач там будет «на 2 минуты» которых можно делегировать аналитикам или тестировщикам.
Например: жуткий цейтнот, время до сдачи проекта пошло считаться на секунды, через 3 часа показ очередного этапа заказчику. Программисту нету времени на тестирование вообще. Он может зафигачить очередную кнопочку, код к ней, и не почти тестируя отправить ее на тестировщика. Пусть он потратит 5 минут на тестирование, работает ли вообще эта кнопочка, а ты за эти 5 минут напишешь еще несколько фичей. Или например, можно самому прочитать документацию чтобы понять ну… какая надпись должна быть вот на этой кнопочке. А можно делегировать это на аналитика, пусть он читает пока ты пишешь фичи, и вернется уже с конкретной строкой, которую нужно вписать в название кнопки.
Но так как человек не может эффективно работать по иерархии, такая последовательность мгновенных и отложенных действий все равно разлинеивается в список задач. А раз мы имеем список задач, то можем отправить его на вход GTD-алгоритму.
Мне кажется, что GTD подход это чуть ли не самое ценное из того, что позволяет не сойти с ума в декабре (когда как известно люди начинают работать с продуктивностью в тысячу раз больше обычной, чтобы успеть дофигачить все задачи) =) Если под рукой нету WBS'ов, их проекций в линейные списки-представления, и четкого алгоритма по тому как их парсить, мозг пытается включить интуицию и просто сгорает на перевычислении этих вещей на ходу.
Вы описали методику разработки под названием Scrum?
Когда я вижу подобные блок-схемы, мне почему-то всегда вспоминается Том Смиковски из «Office Space» и его произведение:
Видимо, в реальном мире у Тома все получилось, он открыл консалтинговую компанию и учит других правильно работать.
Видимо, в реальном мире у Тома все получилось, он открыл консалтинговую компанию и учит других правильно работать.
Sign up to leave a comment.
Прочь из моей головы. GTD в разработке