[копипаст] «О сроках разработки программ»

Нытик-копипаста горе-погроммиста. Мнение чересчур уж полярное, а истина всегда между полюсов.

Например?

У Гласса в фактах и заблуждениях, написано, что программисты назвали своим самым успешным проектом, проект, который они в полной мере закончили удовлетворив всем требованиям, но при этом просрочили его на несколько месяцев и не влезли в бюджет, а для менеджера — это был самый не успешный проект.

Немного дополню.

Этот птсо читал вчера и на сегодня остался осадок в виде: „мы все (Программисты) не ремесленники. Мы художники. Творцы. Мы требуем к себе Уважения и права просирать сроки за чужой счёт. А если вдруг продук^WПроизведение создано вовремя, то нам вообще памятник надобнен золотой, но мы ещё и скромны, потому хватит и серебряного“.

[lurkspeak]ЧСВ в статье over 9000[/lurkspeak]

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

Вообще лучше Гласса почитать, он аргументированно пишет.

Нельзя говорить начальству/менеджменту так: «Я это буду делать от 2 дней до 2 месяцев». Нужно говорить: «В идеальном режиме, если меня не будут дергать на другие задачи, если мне предоставят все условия, если не будет меняться ТЗ (еще несколько „если“ по вкусу), то я это сделаю за N дней (N высчитывается по формуле минимальный срок*2,5, т.к. продолжительность периода отладки действительно хрен предскажешь). Если же будут возникать проблемы в виде постоянного перебрасывания на другие, даже пустяковые задачи, внесения правок в ТЗ (еще куча всякого по вкусу), то срок может измениться вплоть до N*100500». Так и начальник/менеджер видит, почему может затягиваться проект, и задница программиста подстрахована. Ну и ТЗ, естественно, должно быть максимально подробным, чтобы исключить внезапные нежданчики.

Снова уточню: тебе есть что сказать о конкретных выводах?

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

а для менеджера — это был самый не успешный проект

Значит менеджер был неуспешный.

Если менеджер - это человек, который доносит до архитектора пожелания заказчика, собственно общается с заказчиком и обеспечивает следование срокам... То сроки - это забота менеджера, нет? Почему т.н. руководителю нужно объяснять от чего зависит производительность т.н. сотрудников? Это его непосредственная работа.

А если этот «эффективный» кусок говна умеет только отчёты строчить да клиентов подмазывать, то он и не должен делать то, чего не умеет - обозначать сроки.

Не рассказывай мне как через жопу обычно всё устроено, я не по наслышке знаю. И думаю что либо человек не понимает и ты ставишь его перед фактом: от 2-х недель до 2-х месяцев, либо он понимает и сам расспрашивает тебя что и сколько времени займёт.

Менеджеры редко когда полезны в программировании. Вот программисты-начальника - да, они полезны.

Выше верно сказали что «менеджер» должен пиццу заказывать. Больше от них пользы в офисе нет.

Мы художники. Творцы. Мы требуем к себе Уважения и права просирать сроки за чужой счёт.

Потому что, если программа сложнее Hello world заранее очень трудно спрогнозировать сколько времени займет ее разработка и отладка. Могут быть десятки причин для увеличения срока на ровном месте казалось бы. Например, внезапно выяснится, что сторонние библиотеки глючат. Или что чего-то не учли в исходном ТЗ и куча всего еще бывает.

студент попал на работу

В идеальном режиме, если меня не будут дергать на другие задачи, если мне предоставят все условия, если не будет меняться ТЗ (еще несколько «если» по вкусу), то я это сделаю за N дней (N высчитывается по формуле минимальный срок*2,5, т.к. продолжительность периода отладки действительно хрен предскажешь)

Утопический коммунизм.

В 99.9% заказчик сам точно не знает что он хочет. ТЗ обязательно БУДЕТ меняться!!! Это аксиома.

Так что N*100500 это цифра для манагера.

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

Но аффтар видимо не в курсе, поэтому льет розовые сопли про богоизбранность программистов и духовность разработки.

В ЭТОЙ стране от дебилов коммунистов избавились, думали что избавились, на деле же они никуда не делись, просто записались переквалифицировались в менеджеры Менеджер тот же самый крассный комиссар, способы и методы решения задач одинаковые, только цель у первого личные корыстные побуждения а у второго абстрактное недостижимое счастье

кто тебя так обидел?

Ленин же

а для менеджера — это был самый не успешный проект

отсюда вывод: стоит расстрелять всех «эффективных» менеджеров и оставить только неудачных, и мы сразу по уровню жизни переплюнем Японию с Швецией

а что не так? это же не рудник с медью копать, и не тойоты собирать, где вообще роботы людей заменили. замени программиста роботом, полностью замени, пробуй

Это вообще любой проектировочной деятельности касается.

Коммунисты тут ни при чём. Этот метод к коммунизму вообще никак не относится, что и подтверждается практикой.

внесения правок в ТЗ (еще куча всякого по вкусу)

Универсальный ответ «Право заказчика» :)

Нытик-копипаста горе-погроммиста. Мнение чересчур уж полярное, а истина всегда между полюсов.

У меня было достаточное количество таких полярных менеджеров, а некоторые из них, подозреваю, и вовсе биполярные, ЕВПОЧЯ.

Универсальный ответ «Право заказчика»

Ответ неполный. Полный такой - «Любой каприз... За ваши деньги»

(Заказчик) — К сожалению, мы будем вынуждены прекратить сотрудничество. Вам никогда не удавалось понять нас с первого раза. Да, мы не всегда сами знаем, чего хотим, но это не повод делать так, чтобы пришлось переделывать и срывать все мыслимые и немыслимые сроки. Вы, в конце концов, профессионалы.

Ты будешь смеяться, но я такое в свой адрес слышал.

Дык... Деньги манагеры с заказчиком пилят. А это («право заказчика») универсальный ответ манагеров нижним звеньям пищевой цепочки :)

lenin? Сочувствую.

Грэма Гласса?

Ох, как-то не замечал, что их двое. Роб Гласс — Факты и Заблуждения Профессионального Программирования.

Спасибо.

Грэм Гласс - Unix для программистов и пользователей.

Ну и ТЗ, естественно, должно быть максимально подробным, чтобы исключить внезапные нежданчики.

Практика показывает фантастичность этого пункта. Лично я представляю ТЗ (лучше назвать это Implementation Proposal) так - это набор перечислимых пунктов по которым я могу по завершении работы загибать пальцы: это сделано, это сделано, это работает, это я забыл и т.д.
В результате ТЗ надо писать самому собирая воедино броуновское движение обрывков великих и неповторимых мыслей заказчика.
А если этого ТЗ нет, и писать его надо самому, и не дай Патрик придется систематизировать мысли нескольких среднестатистических туповатых служащих? Срок разработки с какого момента отмерять?

Вот реальный пример из жизни. 9 числа объявляется некий заказчик, показывает пальчиком, что нужен сайтик как у тех чётких пацанов, далее по тексту: Мерседес но не машина, без колес и вообще из бревен. Просит дать оценку изготовления до 23 числа. Там будет какой то великий день, с которого и в течении двух месяцев можно поиметь профит. Изучив его представления о вселенной (помимо всего прочего и то, что он обратился с аналогичной просьбой еще в десяток мест) даю оценку (сидя перед зеркалом, потому как заказчик видимо занимается решением очень важных вопросов и недоступен): до 23 числа сделаю, но без админки «для чайника». Это потом, если вообще понадобится, и за отдельные деньги.
Теперь ждем его появления. А сейчас уже 11 число вечер, день кончился.
Возникает стойкое подозрение что он объявится, тем более цена демпинговая по сравнению с веб-студиями, 21 вечером и скажет что готов заплатить после окончания тех двух месяцев когда сайт отработает.

И черт бы с ним, но на переговоры и исследование решения вопроса ушло 8 часов. Если завтра не объявится и не примет мое предложение пошлю нафуй.

Тот караулит, этот - спит -
И так весь мир вертится. (с)

Это вообще любой проектировочной деятельности касается.

Собственно да. Даже более того, элементы неожиданности есть в любой работе. Только в проектировании их больше.