Как правильно оценивать сроки на разработку сайта в web студии?
Здравствуйте!
Я начинающий разработчик, работаю в студии по разработке сайтов. Часто у меня просят оценить сроки по разработке шаблонов или доработке сайта. Я стараюсь установить небольшой срок, чтобы не вызывать раздражение у ПМа. Однако на практике часто оказывается так, что в процессе работы возникают подводные камни в виде непредсказуемых багов, технически трудных дизайнерских решений и т.п из-за чего реальные сроки работы над проектами сильно увеличиваются. Особенно сложно оценить то с чем я ещё не сталкивался, даже примерно сравнить, как правило не с чем(
Как можно решить эту дилемму?
Я стараюсь установить небольшой срок, чтобы не вызывать раздражение у ПМа.
В этом и есть главная ошибка.
Когда планируете срок выполнения работы, вы представляете себе, что каждый пункт задачи вам будет ясен и не придется разрешать никаких неопределенностей. Кажется, что будете все время срока заняты решением одного проекта и никто вас не будет отвлекать.
1. На каждый пункт выполнения задачи нужно делать поправку на то, что вы заняты еще каким-то параллельным проектом или иной регулярной работой. (этот пункт спокойно может умножить время на 2 или на 3).
2. Во время ознакомления с очередным пунктом задачи проекта существует вводный период входа в задачу. Вы выясняете что для этого нужно сделать, ковыряете источники, делаете какие-то эксперименты, что-то пробуете и т.д. Этот период нужно закладывать в сроки выполнения. (может занять от 30% до 80% времени выполнения задачи).
3. Любая задача в процессе решения может раскрыть еще подпункты. (этот пункт может смело умножить время на 2 или 3 и тд).
Есть более простой эквивалент подсчета времени, вместо пунктов 1,2,3.
Представьте, что вы выполняете тот же самый проект, вам дали время чисто на его выполнение, никто не отвлекает вас, все задачи как вы видите в списке имеют довольно понятное решение. Но есть маленький нюанс - вы до крайней степени пьяны, и еле соображаете.
Исходя из этого отягощения и пытайтесь найти макс. время выполнения проекта.
Психология:
Вас спрашивают про сроки, чтобы планировать другие задачи, а вы слышите это как "чувак, мне надо быстрее", и в страхе потерять работу, заявляете крайне малые сроки.
Если у вас есть опыт, то заявляйте срок из формулы (фото в ответах), иначе говорите:
"Регламентированный срок выполнения задачи 14 дней!", даже если ее делать один час.
Обоснование: разработка, тестирование, внедрение, исправление+закладываем форс мажорные ситуации (отключение света, поломку компьютеров....), ссылаемся на большой поток клиентов, сложность задачи...
Главное вовремя предупредить клиента, что работа задерживается. Я обычно говорю - чтобы сделать задачу немного лучше, мне требуется дополнительное время.
--
Увы, но часто я сталкивался с тем, что меня торопили, я ночами не спал, не ел...чтобы сделать как можно скорее, а потом оказывалось, что результат задачи откладывался в "ящик" и так и лежал мертвым грузом. Это люди придумывают работу ради работы. В таких случаях я придерживаюсь точки зрения - "5 лет твой сайт глючил, пару дней подождет, ничего не случится...")) Торопится он...
Увы, но часто я сталкивался с тем, что меня торопили, я ночами не спал, не ел...чтобы сделать как можно скорее, а потом оказывалось, что результат задачи откладывался в "ящик" и так и лежал мертвым грузом. Это люди придумывают работу ради работы. В таких случаях я придерживаюсь точки зрения - "5 лет твой сайт глючил, пару дней подождет, ничего не случится...")) Торопится он...
Это бесит жесть. Буквально на днях общались я, ПМ, и заказчик. Я говорю срок 5 февраля, но меня будто в упор не слышат и продолжают что-то буровить про 29 января, я снова заявляю что 5 февраля, но мне опять задают вопрос про закончить на конец этой недели. Они сами не пробиваемые, у них вечно все счет идет на часы и секунды. На прошлом проекте считали часы и минуты, а в итоге прошло уже пол года, а рекламу так и не пустили, зато костылей наделали.
Вас спрашивают про сроки, чтобы планировать другие задачи, а вы слышите это как "чувак, мне надо быстрее", и в страхе потерять работу, заявляете крайне малые сроки.
Вероятно вы правы, где-то в глубине сознания, я чувствую как меня подгоняют, особенно если ПМ слишком эмоционален (девушка, бывший руководитель продаж), поэтому пытаюсь уменьшить сроки, даже если она говорит что ей это нужно для заказчиков.
Пока буду пробовать называть два срока - минимальный и максимальный. Реальный срок вероятно будет где-то посередине. Ещё ссылаться на отвлечение к другим задачам, если такие будут (а это происходит не редко)
mprog54, если отвлекают на другие задачи, даже мелкие, обязательно это записывайте. Потом будет что ответить. Руководство такие мелочи не помнит или не хочет помнить.
Это бесит жесть. Буквально на днях общались я, ПМ, и заказчик. Я говорю срок 5 февраля, но меня будто в упор не слышат и продолжают что-то буровить про 29 января, я снова заявляю что 5 февраля, но мне опять задают вопрос про закончить на конец этой недели. Они сами не пробиваемые, у них вечно все счет идет на часы и секунды.
Именно так, у них действительно счет может идти на часы, и то что вы сделаете к 5, уже будет не нужно. Сами старайтесь не быть "непробиваемым", попробуйте что-то предложить. Быть может возможно декомпозировать задачу и привлечь еще ресурсы разработки. Может можно пожертвовать каким-то функционалом на запуске 29 и доделать его позже. Я не говорю что ПМ молодцы, а разработка нет, без понятия в чем и ком у вас затык. Но я много раз уже видел жалующихся друг на друга бизнес и технарей, каждый из которых уверен что он молодец, а общая проблема - это проблема кого-то еще, а не его.
Vitsliputsli, ну там посыл был на то что, а могу-ли я бросить все свои планы и поработать сверх, в выходные и тд., чтобы просто что-то им показать к этому сроку чтобы они были довольны. А то что это просто их бзык, а не мой можно доказать тем что основным фукционалом проекта будет интегрированный зум и оплата. И если с зумом еще более менее понятно что делать, могу на своем аккауте делать, то по платежной системе они еще думают какая будет. Так вот... я работаю не первый год и знаю когда действительно нужно, а когда это просто очередной закидон чтобы верхушка в ладошки хлопала какие они молодцы что так все спланировали. Просто в таких ситуациях есть один фактор, оплата. Действительно жмет? Давайте таксу х2, не готовы значить не жмет! Работаю на поддержке одного проекта и у нас такая практика на ура заходит с тех пор как ввели повышение за срочность, и если раньше было что все задачи нужно закрыть чуть ли не в первый день спринта, то после ввода х2 не было ни одной срочной задачи.
Константин Б., да, бывает и такое, что строки уже ...сорваны, из-за того что во время не сделали и не передали в разработку, и это пытаются компенсировать за счет разработки. Сверхурочные, такса х2 - это очень плохие решения. х2 не готовы дать, скорее всего потому, что не могут такое согласовать, а не потому что задача не нужна. Но, у вас явное противостояние с бизнесом, а это очень изматывающая вещь для обоих сторон и большая проблема в плане производительности.
