То, что всегда приходит неожиданно, или вопрос о ср*ках

Нравится

Send

Мнение автора может не совпадать с мнением редакции

Всем привет!
Пока мой успешный и популярный бложик совсем не стух, решил, вот, порадовать случайного читателя очередным постом.
По проекту, значит, новости вот какие:
Доделан функционал, все работает. Теперь черед за юзабельным дизайном, ну и вообще за графической концепцией.
Весь код по проекту я переписал с нуля.
Почувствовал свой прогресс как программиста - код по сравнению с предыдущей версией сократисля в 4(!) раза!
Может быть это случилось потому, что я выбросил ненужные "киллер фичи" из прошлого релиза.
Может быть потому что научился пользоваться функциями :)
Расту, чо!

Кстати.
Изначально я не собирался все делать заново - думал - просто подправить косячки, ну, может быть освежить дизайн. А потом все как-то пошло-поехало. Поэтому, когда было 10 число, я думал, что к 20-му доделаю вообще все.
Но, сегодня 22-е, а работы еще не мало.

====================
Так вот, сегодня вместо поучительной минутки будет познавательный вопрос:
====================
Дорогой, уважаемый, случайный читатель - а как лично ВЫ решаете вопрос укладывания в сроки и соответствия дедлайнам? Не важно - личная ли это сфера, или вы думаете за всю команду.
Как вы изначально устанавливаете сроки? Особенно, если задача не типовая?
Можете ли сдвигать сроки выполнения, или предпочитаете биться 24/7 до самого конца, главное, чтобы вовремя?
Есть у вас секрет установки комфортных сроков и несрываемых дедлайнов?
Поделитесь, пожалуйста.
Тем более, что у нас тайм-менеджерский проект и любая информация будет не только интересной, но и полезной!
Спасибо!

В избр. Сохранено

Нравится

Комментарии

VJ-X

Модульная система управления предприятием для малого бизнеса

Ян 38

22 янв 2014

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

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

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

Ответить

Имя Фамилия

22 янв 2014

Последние пару лет я работаю по Scrum. Его позиция такая: "сроки, люди и бюджет фиксированы, а скоуп задач - нет". Т.е., чтобы "успеть", мы делаем ряд шагов:
1. Нужно знать, что ты делаешь.
Поэтому мы описываем ряд задач, которые мы видим и сортируем их в порядке "can't live without" - наверху. Мы делаем это, например, в Basecamp, но это лишь вопрос выбора инструмента и все.
2. Определяем лист задач "на сегодня". Т.е. каждое начало работы (не рабочего дня, а "вот я сел работать") начинается с вопроса: а что мы можем зарелизить уже сегодня? Вот прям сделать, проверить и сразу же в продакшен и сегодня. Не важно насколько оно маленькое, но важно - чтоб оно было из топа того самого листа из п.0 - из "can't live without". Т.е. не "сайт за неделю", а "страничка за день" или "что-то за час". И сарзу в продакшен. Это очень важно и очень заряжает и мотивирует. Каждый день релиз - это очень мотивирует.
3. Если задача из п.0 слишком большая, чтоб сделать ее за день, то это значит, что это на самом деле не задача из п.0. Т.е. ее надо поделить и разрезать и сделать так, чтоб задача была поставлена так, чтоб ее можно было сделать сейчас и зарелизить сегодня. Да, это приведет к увеличению числа задач и к отодвиганию других задач еще дальше по списку из п.0, но это произошло из-за более четкого понимания сложности задачи. Это нормально.
4. Все вышесказанное приводит к позиции "Делать меньше". Это и облегчает задачу и заставляет концентрироваться на самом главном. Делай меньше, да лучше. Это работает еще и потому, что когда мы делаем качественно, мы работаем на низком уровне, а любые изменения на низком уровне приводят к мультипликативным изменениям в продукте. А работа на высоком уровне приводит к аддитивным изменениям. Благодаря качественной работе результаты работы от мультипликативных изменнеий начинают просто поражать. Иногда от этого вылазят баги, но мы окей с их существованием. Для нас гораздо важнее тот эффект "изменил в одном месте, а изменилось везде", "нажал 1 кнопку и все заработало". А со временем твой профессионализм растет и в совокупности с качеством продукта, которого мы так добиваемся, это приводит к все меньшему количеству багов.
5. Есть еще так называемая Scrum-линейка. Она полезна для визуализации задач. Например, задача: ремонт квартиры. Нужно:
а) поклеить обои
б) покрасить потолок
в) заменить электропроводку
г) покрыть ламинатом пол
и мы просто прикидываем какая задача сложнее какой на наш взгляд. Получается линейка вроде:
покрасить потолок \ поклеить обои \ покрыть ламинатом пол \ заменить электропроводку
Затем нужно оценить масштаб работ относительно простой и понятной задачи - например, "покрасить потолок":
покрасить потолок - 1 у.е.\ поклеить обои - 3 у.е.\ покрыть ламинатом пол - 4 у.е. \ заменить электропроводку - 6 у.е.
Начинаешь делать первую задачу (это не обязательно первая из списка) и понимаешь, что ты ее сделал за 3 дня. А она соответствовала 3 у.е. на шкале линейки. Теперь ты примерно знаешь, что для тебя по твоим ощущениям 1 у.е. это 1 день и задачи на 6 у.е. это задача примерно на 6 дней. Это помогает планировать большие скоупы задач. Не очень точно, конечно, но все же достаточно точно и со временем этот глазомер только улучшается.

Ответить

VJ-X

Модульная система управления предприятием для малого бизнеса

Ян 38

22 янв 2014

Интересно )

Ответить

Aplan

Тайм-менеджер, ежедневник, задачник

Сергей Андреевич

23 янв 2014

Воу! Круто!
А когда работаете командой - вы, получается, вообще стратегических сроков не ставите? Просто постоянно идет работа в потоке?
А KPI есть какие-то?

Ответить

Имя Фамилия

23 янв 2014

Сроков стратегических нет, есть стратегические цели. Как без них? Мы понимаем, что поставленные цели реальные, достижимые и мы с запасом успеваем их достигнуть к такому-то числу.
Вот, недавний пример: в июле 2013 г, когда мы начинали, мы закомитились сделать поддержку айпи телефонов и многопользовательности аж к 15 января 2014 г. Айпи телефоны у нас уже работали, прикрученные ручками, в августе, затем, в тестовом режиме у разработчиков в октябре. А многопользовательность была заложена изначально и мы ее просто вели все это время. Но мы айпи телефоны выпустили только 10 января 2014 г, потому что вылезло столько непредвиденных задач по юридическим документам и бухгалтерской отчетности, и чего только не было, что мы были вынуждены остановить всю разработку по основной услуге и продукту и начать делать нецелевую, совсем неинтересную часть системы, т.к. без нее мы бы не смогли бы нормально продавать ни айпи телефонию, ни нашу многопользовательность.
В итоге и сроки были соблюдены и еще куча всякой непредвиденной ерунды по ходу прикручено. Оттестировано все и сделано даже лучше, чем задумывалось.
Сейчас у нас новая задача к лету. И она уже не столько техническая (технические аспекты тоже есть), сколько финансовая. Мы хотим конкретные цифры-показатели по деньгам к нашему году работы.
Про KPI до сего момента не слышал, с темой не знаком, почитаю, спасибо! Но если говорить о каком-то индикаторе успеха - то это как раз и есть это достижение поставленной стратегической задачи в указанный срок. А т.к. задача ставится предельно конкретно, то мы сразу видим: сделали или нет.
Спасибо за вопрос!

Ответить