Имелось ввиду комментирование псевдоготового результата. Неоттестированное толком приложение демонстрировалось заказчику, после чего появлялась еще кучка требований и комментариев к программе, способу ее работы и взаимодействию с окружающим миром. Ну а так как у нас результат все же с приставкой псевдо-, то недоработки в том, что показывалось, возникали неизбежно. Как следствие, чтобы сгладить проблему нерабочей программы (которую, попросту, надо было оттестировать корректно, ибо сроки все равно увеличивались в два раза от озвученных мною и в 4 — от спущенных сверху в виде дедлайна), то эти комментарии принимались.
Я допускаю, что на самом деле их было гораздо больше, как мне и было озвучено. Просто героические усилия и солидарность приводили к тому, что я получал 30% от озвученных пожеланий. Так это или нет — легче от этого не становилось. Перекраивать приходилось огромные куски программы, причем перекраивать на скорую руку, ибо следующий дед лайн был еще оптимистичней предыдущего. И так далее.
Постоянно использую agile в разработках. Но когда по всем нормативам получается 80 часов, которые под лозунгом «даешь пятилетку в три года» трансформируются в 30 часов, никакая система не поможет. Урезание, и зачастую за счет тестирования и отладки
Именно.
А если быть совсем точным, то изначальный уровень абстракции был попилен в угоду количеству комментариев и переделок и постоянно сокращаемым срокам. В результате — костылестроение
Может наоборот плюс? Главный бич всех таких поделок — охлаждение. Ну не получается все в одном — и производительность, и теплоотвод. Так что это скорее не минус, а плюс, который может не давать железке выполнять роль кипятильника
Как бы это помягче сказать… Суперкласс, 40 входных переменных, хранение данных предварительных рассчетов в массиве выходных данных, который под темповые области вручную увеличен в два раза (вместо размерности [x,y,z], которая описывает иерархию, выполнен в виде [x, y, 2z]), да и вообще — хранение данных в ООП языке в стиле процедурного программирования… Боюсь, юнит-тесты вызвали бы гору непонимания и долгие объяснения «как, что и зачем».
Потому что результатом работы должен являться продукт, а не процесс. Процесс заказчику не сдашь. Более того, это начинает постепенно накладываться на другие запланированные задачи, откладывая точку их начала — далее наваливается как ком.
Я говорил о рабочем процессе, в котором есть постоянная команда, которая не успевает. но никак не о крайнем случае заморозки проекта и его последующем форсировании.
Спасибо за Ваш ответ. Собственно, тезисно по Вашей статье я прошел, не буду повторяться.
что касается систем управления проектом, то на мой взгляд, они очень и очень сильно схожи с проблемами, стоящими перед одним программистом.
Давайте немного раскрою мною же и выданный постулат:
Проблемы есть везде. У менеджера, у программиста. И у того, и у другого корень проблемы практически всегда один и тот же. Согласование рабочего процесса для менеджера = ожиданию программистом кода от другого участника. И там и там возможны задержки, накладки.
непостоянство технического задания одинаково ударяет что по менеджеру, что по программисту
нехватка ресурсов может ощущаться и там и там.
Одним словом — проблемы прямо рядышком. Менеджеру даже проще — у него больше возможностей для их решения.
Ни с каких. Сколько бы не брал примеров из личной практики, какой бы ни был проект — приплюсовывание рабочих рук на позднем этапе с явным запаздыванием ведет всегда только к лишней нервозности и беготне по кругу. Полностью с Вами согласен.
Не всегда так.
Да, я не раз встречал со стороны заказчика непонимание, когда в ведомости проекта значилась строчка «менеджмент проекта». Но, как правило, это решалось достаточно просто — вот тебе дизайнер, вот программист, вот архитектор, вот разработчик базы данных. Работайте. Особо упертым хватало 3 дней, чтобы понять, что это АД.
С другой стороны, при правильной постановке рабочего процесса, вопросов не возникает. По сути дела данная должность — прослойка между руководителем и группой программистов (берем только ситуацию с оценкой результатов, на самом деле предметное поле несколько шире). Если человек, занимаемый должность, не перекладывает на плечи начальства мелкие проблемы коллектива, а на плечи коллектива — спускаемые директивы начальства в прямом виде, то он как раз и выполняет то, зачем он работает — несет полную ответственность за вверенный участок работы. Потому отчитывается перед начальником он. И в голове начальника прежде всего не «ой какая крутая группа программистов, которая все сделала», а «ой какой Вася/Петя/пофиг как зовут молодец, правильно поставил рабочий процесс и все сделал вовремя». Да, группа программистов стоит за плечами этого руководителя, и их успеха никто не умаляет. Это те люди, чьими руками ковалась победа. А тим лид при этом — тот, кто привел к победе. Так что вроде все закономерно.
Когда статья больше похожа на обсуждение новой бехи жалобу на то, как страшно жить, то смысл ее писать? А тем более мне странно то, что пришла она из песочницы. Каг бэ да, пожаловаться на жизнь — это завсегда, но в рамках статьи да еще и с получением инвайта?..
Я допускаю, что на самом деле их было гораздо больше, как мне и было озвучено. Просто героические усилия и солидарность приводили к тому, что я получал 30% от озвученных пожеланий. Так это или нет — легче от этого не становилось. Перекраивать приходилось огромные куски программы, причем перекраивать на скорую руку, ибо следующий дед лайн был еще оптимистичней предыдущего. И так далее.
А если быть совсем точным, то изначальный уровень абстракции был попилен в угоду количеству комментариев и переделок и постоянно сокращаемым срокам. В результате — костылестроение
что касается систем управления проектом, то на мой взгляд, они очень и очень сильно схожи с проблемами, стоящими перед одним программистом.
Давайте немного раскрою мною же и выданный постулат:
Проблемы есть везде. У менеджера, у программиста. И у того, и у другого корень проблемы практически всегда один и тот же. Согласование рабочего процесса для менеджера = ожиданию программистом кода от другого участника. И там и там возможны задержки, накладки.
непостоянство технического задания одинаково ударяет что по менеджеру, что по программисту
нехватка ресурсов может ощущаться и там и там.
Одним словом — проблемы прямо рядышком. Менеджеру даже проще — у него больше возможностей для их решения.
Да, я не раз встречал со стороны заказчика непонимание, когда в ведомости проекта значилась строчка «менеджмент проекта». Но, как правило, это решалось достаточно просто — вот тебе дизайнер, вот программист, вот архитектор, вот разработчик базы данных. Работайте. Особо упертым хватало 3 дней, чтобы понять, что это АД.
С другой стороны, при правильной постановке рабочего процесса, вопросов не возникает. По сути дела данная должность — прослойка между руководителем и группой программистов (берем только ситуацию с оценкой результатов, на самом деле предметное поле несколько шире). Если человек, занимаемый должность, не перекладывает на плечи начальства мелкие проблемы коллектива, а на плечи коллектива — спускаемые директивы начальства в прямом виде, то он как раз и выполняет то, зачем он работает — несет полную ответственность за вверенный участок работы. Потому отчитывается перед начальником он. И в голове начальника прежде всего не «ой какая крутая группа программистов, которая все сделала», а «ой какой Вася/Петя/пофиг как зовут молодец, правильно поставил рабочий процесс и все сделал вовремя». Да, группа программистов стоит за плечами этого руководителя, и их успеха никто не умаляет. Это те люди, чьими руками ковалась победа. А тим лид при этом — тот, кто привел к победе. Так что вроде все закономерно.
обсуждение новой бехижалобу на то, как страшно жить, то смысл ее писать? А тем более мне странно то, что пришла она из песочницы. Каг бэ да, пожаловаться на жизнь — это завсегда, но в рамках статьи да еще и с получением инвайта?..