alex55555Програмёрэмм.. ну я то вообще на 1.5 умножаю, потому взял на заметку, что надо больше коэффициент брать.
Ты, по ходу, погонщик рабов, а не программёр.
ПрограмёрЯ в душе перфекционист и потому не смогу жить спокойно, пока не добьюсь того, чтобы я называл срок разработки...
Ты называй, но толку всегда будет мало. Ты хочешь всё, а те, кто тебе это всё делает, не хотят страдать из-за твоего перфекционизма.

Ну и так, для общего развития - срок будет точным, если ты (лично ты, а не исполнитель) сумеешь предсказать все (подчёркиваю - все ) факторы, влияющие на разработку.

И немного с небес на землю - ты не всемогущ (тупо срок считать не умеешь), поэтому не бей подчинённых, они тоже не всемогущи.

alex55555, вопрос читать не пробовал? :)) Ну так, чтобы глупости не говорить принимая участие в серьёзной беседе...

maytonКстати наличие и отсутствие BA в команде тоже сильно меняет оценку.
И сама команда.

В небольшой команде уже работал, сейчас команда набирается... пытаемся взять нормальных мидлов на удалёнку с ЗП тысяч 80-100, а к нам какие-то неучи приходят, 80% из которых отсеиваем по собеседованию (идут на мидла и не знают что такое абстрактный класс и чем от интерфейса отличается... вообще бред какой-то), а остальных по первым нескольким дням работы... уже заколебался... собеседований 30 провели и с трудом нашли одного мидла и одного джуна :) К нам даже Senior один (он так себя позиционировал) пробовался на 120к, рассказывал что всё знает и вообще суперкрут... не досидел даже до конца собеседования со словами "да, я понял.. я не знаю настолько, насколько думал, я Вам не подхожу, надо ещё учить, до свидания". Короче вообще как-то печально в вэбе нынче :((

А насчёт ВА... мне это сокращение не знакомо... что это значит? ^_^
Может нам кого-то и правда донанять стоит и всё сразу в гору пойдёт и он меня научит правильно задачи оценивать :))

maytonBA - Business Analyst. Это человек который будет посредником между бизнесом и разработчиками.
Чем крупнее проект - тем этот загадочный господин нужнее. Он кстати на своём уровне избавит
вас от ненужной переписки в почте. Он - оценивает бизнес-ценность задач и помогает выставить
приоритеты. Вобщем никто вам в спринт не вбросит всякую фигню за 1 день до релиза.

а.. понял. Да, про бизнес аналитика читал в "Идеальный программист".
насчёт фигни за день до релиза, у нас спринты в момент старта "блокируются" (то есть как только я нажал старт, спринт менять нельзя, за редким исключением, когда типа офис клиента сгорел и потому в спринт правку нужно внести с учётом этого :)) ). Я на этом сильно настоял, потому что без этой практики вообще нынче нормального организованного процесса разработки не представляю. У нас пока другая проблема, думаю это тоже бизнес-аналитик как-раз решать должен: бывают случаи, из-за недостаточной организации процесса бывают случаи, когда не удаётся полноценный спринт собрать, и потому получается или 3 спринта по полтора дня каждый, или просто каша из намешанных задач не имеющих никакого отношения друг к другу, типа поменять вёрстку, поправить что-то в каталоге, поставить ограничения на стоимость покупки и т.д... ну то есть типа "разное", без какой-то конкретной запланированной цели, что малёк бесит :)

mayton,

За Макконнела спасибо! Очень полезной книга оказалась. Сразу стало понятно где есть проблемы, какие, и как решать. Правда немного печально, что проблемы обнаруживаются уже на уровне фреймворка, но думаю со временем соображу как эти дыры закрыть можно... ну или на другой фреймворк переедем потом :)