beast_in_cage: (geek)
[personal profile] beast_in_cage

Заметил, что на работе вечно не хватает времени на выполнение задач. Пол-беды, что их много, а исполнителей мало.

Основная проблема у меня с переключением между «текучкой» и интересной задачей (да, текучку я, мягко говоря не люблю - нет развития). Когда погружен в задачу, а тут «задампь нам базу, плииз», то после этой пятиминутной задачи минут 15 въезжаю в основную. Я долго отлынивал от «текучки» всеми возможными способами. Но несколько дней тому назад я «придумал» следующую стратегию.

Огромная просьба, комментировать и предлагать свои варианты или пути преодоления подобной проблемы.

Шаг 1. Определить основную цель задачи. Например, спроектировать систему резервного копирования. Проект такой системы и будет конечной целью задачи. Обязательно описать, хотя бы в двух словах, задачу.

Шаг 2. Определить и описать (как можно подробнее) под-задачи или промежуточные вехи. К примеру, определить что хранить, как часто делать копии, сколько хранить, где хранить, и т.д. Это поможет находится и думать в пределах задачи и не распространяться на несущественные моменты, которые могут еще 100500 раз поменяться. Этот шаг очень важный. Здесь, также, необходимо подумать об описании проекта (создать документацию).

Шаг 3. Определение времени на выполнение каждой из вех, время на изучение вопроса (чтение интернетов, форумов, общения с коллегами) также ДОЛЖНО учитываться. Это необходимо для оценки времени выполнения задачи (пусть даже приблизительное). Например, исследование - 2 часа, определение данных для хранения - 1 час, разработка схемы копирования - 2 дня, и т.п.

Шаг 4. Определение атомарного времени выполнения подзадачи, т.е. промежуток времени, в котором можно вcецело отдаться задаче и прерваться ТОЛЬКО по истечении этого «кванта». Например, положим, что 30 минут времени разрешаю себе не обращать внимания на другие задачи.

Шаг 5. Разбить подзадачи согласно принятому «кванту». Если оценочное время для вехи больше чем «квант», вернуться к шагу 2 и выделить под-под-задачи, которые могут уложиться в принятый «квант». По истечении этого времени желать пометку о следующем:
- что было сделано;
- что осталось;

После выполнения вехи сравнить время оценочное и реальное. Если разница меньше 30%, то Вы молодец, если больше - значит умение предсказывать придет с опытом ;-)

Спасибо за внимание

Date: 2012-06-07 07:12 pm (UTC)
From: [personal profile] gest_hds
Обязательно добавить пару буферных часов в день на непредвиденное.
Иметь список дел "на пять минут" на случай небольших перерывов.

Date: 2012-06-08 09:24 am (UTC)
From: [identity profile] beast-in-cage.livejournal.com
Спасибо.

Думаю, что непредвиденное - не очевидное, и как следствие не важное (в большинстве случаев). Значит можно "впихнуть" это непредвиденное как-нить потом.

Пятиминутные перерывы лучше посвятить себе - чтение новостей, каментов, форумов или напиткам.

Date: 2012-06-07 07:30 pm (UTC)
From: [identity profile] kimaki.livejournal.com
оооо :)
почнемо в принципі з того, що те, що ви описали є фактично технологією Agile/Scrum, яка зараз дуже популярна в ІТ світі.
щоб з змінила я:
1)"Проект такой системы и будет конечной целью задачи. Обязательно описать, хотя бы в двух словах, задачу."
- це дуже загально. Система для копіювання даних може бути різною, том у описати в 2-х словах задачу недостатньо.
Для того, щоб потім мати можливість все розбити нормально на підзадачі і проставити естімейти потрібна хороша документація. Потрібно чітке розуміння того, що вимагається від системи і які конкретні дані вона повинна видавати потім. Ну і, звичайно, які дані будуть йти в систему.

2) от якраз описання проекту (створення документації) повинно йти першим кроком. Маючи уже готову документацію (в майбутньому допускаються зміни, але в будь-якому випадку стержень - головна бізнес-логіка проекту - мінятися не буде і неповинна).
Маючи таку документацію готовою - набагато простіше розбивати проект на підзадачі.

3) Естімейти. Вони зазвичай робляться в ідеальних годинах. Тобто у будь-якому випадку, навіть якщо ви на всі 200% впевнені в тому, що закінчите якусь задачу за 2 години, наприклад, то це ви ідеальні годинип рахуєте, тому зазвичай множаться естімейти на 2.

5) вважається, що підзадачі повинні бути такими, щоб на виконання їх тратити не більше 4 ідеальних годин (8 не ідеальних), якщо задача більше буде займати по естімейтам - її требюа розбивати ще :)

Ну і останнє - не забувайте про тестування. недостатньо ставити естімейти для девелопмента - потібно ще розуміти, що реально тестування займає 1,5 часу девелопмента, а при дуже великих проектах всі 2

Date: 2012-06-08 09:38 am (UTC)
From: [identity profile] beast-in-cage.livejournal.com
Знову я щось відкрив вже відкрите кимось? нєпорядок (

Дякую за такий розгорнутий камент (думав пів-дня про відповідь). Читаю про вказані методи.

1. Згоден про детальний опис, але його варто писати тоді коли є загальна ідея. Бо для написання докі потрібен час на вивчення предметної області який слід вказати на другому етапі.

2. згоден і добавлю ще сюди створення прототипу.

3. згоден

5. дякую за підказку.

А ось про тестування, впровадження та підтримку (точніше розробка схеми підтримки) я не подумав. shame-shame.

Date: 2012-06-12 07:18 pm (UTC)
From: [identity profile] kimaki.livejournal.com
ну от в моїй компанії ми дієжмо наступними кроками:
1) спочатку в"їжджаємо в тему, мучаємо наш бізнес з точки зору того, що вони хочуть показати новим функціоналом, чого вони взагалі хочуть добитися
2) пишемо документацію з точки зору бізнесу. Тобто описуємо те, як певний функціонал повинен працювати
3) віддаємо на затвердження бізнесу, потім відповідно вносимо правки і все таке. Поки не отримаємо повного затвердження від всіх відповідальних персон (включаючи команду дизайнерів, якщо функціонал потребує frontend робіт), функціонал не йде на девелопмент.
4) віддаємо затверджену документацію девелоперам
5) девелопери при необхідності пишуть технічну документацію (у нас це в основному просто зпаписані якісь особливі моменти з точки зору девелоперів) і розбивають задачу на підзадачі
ну а далі йде стандартний процес розробки + тестування.

Date: 2012-06-08 09:19 am (UTC)
From: [identity profile] sonya-fasonya.livejournal.com
тоже хотела сказать, что это на Scrum похоже.
единственный минус этого - попытка разбить подзадачу на под-под-задачи определенного интервала времени порой занимает больше времени и сил, чем реализация задачи целиком.

еще вопрос, как оценивать реальное время на задачу: считать только те минуты/часы, что потратил именно на задачу или считать время со старта до финиша вехи. если первое, тогда хорошо бы общее время тоже учитывать, чтобы понимать каков процент рабочего дня уходит на рутину.
если второе, то 30% - это очень и очень оптимистично (согласно скраму это получается FF (фокус-фактор)=0.7, что нереально круто, мы выше 0,55 никогда не выходили)

Date: 2012-06-08 10:00 am (UTC)
From: [identity profile] beast-in-cage.livejournal.com
Спасибо за камент.

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

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

Date: 2012-06-08 10:10 am (UTC)
From: [identity profile] sonya-fasonya.livejournal.com
вполне может быть, что сложность разбиения - специфика моих задач, а ваши вполне так побьются - только опыт покажет.

если считать время так, то 30% вполне реальными кажутся.

только все равно, планируя подзадачи надо часть времени отводить на "въезжание обратно". 5 минут, на то, чтобы просмотреть записи и вспомнить (т.е. при планировании учитывать, что есть не 30 мин, а 25)

Date: 2012-06-08 10:14 am (UTC)
From: [identity profile] beast-in-cage.livejournal.com
предполагается, что въехать будет легче по двум причинам:
- старт новой подзадачи;
- есть более-менее четкое описание подзадачи;

ну и документировать действия по схеме надо-сделано-осталось в джире и где-то-еще необходимо.

Profile

beast_in_cage: (Default)
beast_in_cage

January 2015

S M T W T F S
    123
45678910
11121314151617
18192021222324
2526 2728293031

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 21st, 2017 11:07 pm
Powered by Dreamwidth Studios