peer wrote: > > Скажите как себя вести, когда руководством сроки даются нереальные > малые, за которые есть возможность сделать только с кучей багов?
Если в реальном мире, то делать с багами по возможности в срок (учитывая
какие баги ты оставляешь за собой, если профессионализма хватает — нынче
софт с багами — это норма) в то же время прикидывая варианты: на кого
свалить или куда свалить (тут уж как повезет), когда разборки начнутся,
могут и не начаться (может вообще оказаться, что данный проект просто
осваивание средств).
Если в виртуальном, то предложить свою оценку начальству, оно умное и
пресмотрит сроки или изменит функциональность.
Здравствуйте, peer, Вы писали:
P>Привет! P>Скажите как себя вести, когда руководством сроки даются нереальные малые, за которые есть возможность сделать только с кучей багов?
Я порекомендовал бы почитать что-нибудь по управлению проектами, лично для себя я этот вопрос решил.
Основной мотив, что у нас есть треугольник с тремя сторонами: время, ресурсы, функциональные возможности (ФВ), при увеличении, стороны ФВ, у нас автоматом увеличиваются другие — время либо ресурсы. Правда еще нужно набраться смелости обозначить эту позицию начальству (и доказать что это действительно так ) поэтому рекомендую следующую литературу:
Том Демарко — Deadline.Роман об управлении проектами
Том Демарко, Тимоти Листер — Человеческий фактор — успешные проекты и команды
Дж. Маккарти, М. Маккарти — Правила разработки программного обеспечения
можно еще классику Брукса прочитать и Макконела — Профессиональная разработка ПО, ну и дальше в ту же степь.
Правда после прочтения данных книг, вероятно возникновение друго вопроса, что я тут делаю?
Здравствуйте, peer, Вы писали:
P>Привет! P>Скажите как себя вести, когда руководством сроки даются нереальные малые, за которые есть возможность сделать только с кучей багов?
Когда-то давно для себя решил, что на слово "Срочно" отвечаю "Когда-нибудь. После дождичка в четверг".
Здравствуйте, Осака Вестингауз, Вы писали:
ОВ>В серпентарии: любимые работники (начальства), не успев к сроку, "переключаются на более важные задачи", спихивая глючный недоделанный кусок обычным работникам. Обычные работники, доделывающие этот кусок, и особенно — находящиеся в подчинении у любимых работников (и ими оцениваемые), выставляются виноватыми, и, если других заслуг нет, получают пинком под зад. Попытки как-либо вести себя — скорее приведут к получению репутации нелояльного. Остаётся или оказаться любимым работником, имеющим право выбирать себе задачи, или решать проблему за свой счёт (переработки, к которым, собственно, и склоняют, назначая нереальные сроки).
Судя по изложению таких мелких деталей, досталось в жизни... Не в МВ случайно работал?
Здравствуйте, peer, Вы писали:
P>Привет! P>Скажите как себя вести, когда руководством сроки даются нереальные малые, за которые есть возможность сделать только с кучей багов?
Честно предупредить, что конечный результат не гарантирован. Потому что твое руководство дает нереальные сроки, исходя, судя по всему из своего собственного понимания сущности решаемых проблем. Вот это собственное понимание руководства всегда нуждается в нежной корректировке в нужное русло. Поскольку эти люди, как правило далеки от вычислительной техники и разработки ПО и оценивают сложность решения проблем опираясь исключительно на нужды бизнеса. А бизнес и разработки ПО находят лишь две точки соприкосновения — ПО разрабатывается для нужд бизнеса и на на деньги от бизнеса. В остальном система оценок с одной стороны и с другой — небо и земля. Поясню примером: дирек по маркетингу хочет добавить на свою форму отчетности список выбора категории товара и чтобы при его изменении в другом окошке автоматически формировался список товаров, по которым за последнее время были движения. Он считает что это очень просто и говорит что тут работы на полдня. Ему и невдомек что система сильно формализована и для того чтобы это сделать придеться произвести кучу дополнительных операций для реализации данного функционала. Когда программист объясняет ему все это, он встает на дыбы, аргументируя тем, что позавчера ему добавили автоматический выбор дат по складским остаткам за два часа. Всегда ни для кого не было тайной, что большинство людей, имеющих отделенное или опосредованное отношение к компьютерам, не представляет себе реальных трудозатрат по разработке ПО и лепит при каждом удобном случае свои оценки: "да это же как два пальца", "да что там делать — там делать нечего", или еще лучше "чего вы возитесь — я бы сама уже давно сделала" (последняя фраза относиться к главбуху одного банка в котором я работал)
Здравствуйте, DangerRSDN, Вы писали:
DRS>Судя по изложению таких мелких деталей, досталось в жизни... ;) Не в МВ случайно работал?
Нет, в другом гадюшнике.
Здравствуйте, peer, Вы писали:
P>Привет! P>Скажите как себя вести, когда руководством сроки даются нереальные малые, за которые есть возможность сделать только с кучей багов?
Anyway делать нужно так, что бы заказчик (кто бы он там нибыл) оставался доволен. Доволен заказчик -> есть бабло -> довольно руководство -> есть пряники для программеров -> общее счастье.
Повреждение мозга после ректальной биопсии — редкая штука (с) Хаус
Интересные ответы, всем спасибо, но хотелось бы так же услышать коментарии для немного другой ситуации (выше описывалось для анализа сроков длительной задачи): если тимлид ставит небольшую задачу сроком этак 3 дня. Но ты понимаешь, что за три дня ты ее решить можешь как "кодер", а не программист. То есть сделать вполне реально (почти без багов , но не так, как хотелось. А хотелось бы решить где-то за 5 дней, чтобы это был приемлемый код, удобный для последующей подержки. То есть хотелось бы на работе развиваться, а не тупо выполнять таски.
Были ли у кого такие конфликты?
P>Скажите как себя вести, когда руководством сроки даются нереальные малые, за которые есть возможность сделать только с кучей багов?
из моего опыта получается следующее (если проджект менеджер)
1. садишься и рассматриваешь архитектуру, упрощаешь её по максимуму
2. архитектура рассматривается на предмет рисков внесения багов разработчиками и слабые места оптимизируются
3. работы распределяешь так что бы не было конвейерных пузырей, это тоже сильно сократит сроки
4. постоянно контролируешь процесс, это даст еще 10-20% ускорения..
но факт один, если что то разрабатываешь, то не бойся упрощать и отказываться от уже сделанного, так как внесение изменений и исправлений сожрет времени очень много, гораздо больше чем написание нового, оптимизь архитектуру исходя из утверждения Калашникова "то что сложно — не нужно".. я сам несколько "камикадзевских" проектов провел таким образом и удалось снизить количество багов до крайне малой величины и вписаться в сроки..
Здравствуйте, Pro100Oleh, Вы писали:
PO>Интересные ответы, всем спасибо, но хотелось бы так же услышать коментарии для немного другой ситуации (выше описывалось для анализа сроков длительной задачи): если тимлид ставит небольшую задачу сроком этак 3 дня. Но ты понимаешь, что за три дня ты ее решить можешь как "кодер", а не программист. То есть сделать вполне реально (почти без багов , но не так, как хотелось. А хотелось бы решить где-то за 5 дней, чтобы это был приемлемый код, удобный для последующей подержки. То есть хотелось бы на работе развиваться, а не тупо выполнять таски.
Неа, ничего не понятно.
Как хотелось бы тебе ее сделать? Если ты про структуру кода, комментарии и т.д. то лучше так и делать — по факту быстрее получится, чем кое как делать.
Если ты про архитектуру — то не тимлид ли должен ее делать?
Какую тебе вообще задачу дает тимлид? И чем ты хочешь улучшить ее решение? А говорит ли тимлид какого плана решение должно быть в те сроки, которые он озвучивает? А ты ему можешь ведь сказать, что у тебя получится и за какие сроку, пусть он и выбирает — иначе зачем он? Может он тебе еще и подскажет 3й вариант, как на самом деле надо было делать.
Благо тимлид преполагается быть технически грамотным...
В общем, иногда ты лучше разовьешься, тупо выполняя таски под контролем грамотного лида, чем фантазируя что-то свое без опыта.
убедительная просьба следить за объемом цитирования — модератор
F>Благо тимлид преполагается быть технически грамотным...
F>В общем, иногда ты лучше разовьешься, тупо выполняя таски под контролем грамотного лида, чем фантазируя что-то свое без опыта.
Не буду ничего квотить. Мне понравилось очень — две точки зрения: одна программиста, вторая менеджера. Причем менеджер даже не захотел понять то, что имел в виду программист. Кстати все в посте сформулировано понятно и проблема тоже описана. Но вот ее решение лежит отнюдь не в области профессионализма, а в области человеческих взаимоотношений.
Общего алгоритма ее решения быть не может. Pro100Oleh, зависит от твоего менеджера, даже от того с какой ноги он встал с утра, зависит от тебя и того с какой ноги ты встал. В одной ситуации лучше (для тебя, а не вообще) сделать за 3 дня и с багами, в другой за две недели, но без оных.
Как помошь тебе следующие вопросы:
1. Насколько проблематичны для конторы будут те баги, что ты сделаешь? Возможно их исправление в последующем — это естественный процесс работы вашей конторы и за оное контора тоже деньги с заказчика.
2. Какова вероятность, что твой код не выкинут через месяц, за ненадобностью заказчику? Часто бувает, что какая-либо функциональность нужна только через 3 дня, а потом про нее забывают и забивают.
3. Насколько заинтересован твой тимлид в сроках или качестве? Что для него важнее в данном проекте?
4. Готов ли он выслушать твои предложения и пойти тебе навстречу? Может быть ситуация, когда любое твое предложение будет воспринято в штыки — тимлид твой человек такой.
интересно, кстати, было бы услышать рассуждения на вот какие моменты:
V>1. Насколько проблематичны для конторы будут те баги, что ты сделаешь? Возможно их исправление в последующем — это естественный процесс работы вашей конторы и за оное контора тоже деньги с заказчика.
что мешает сделать без багов, но взять с заказчика деньги на их "исправление"? это же выгоднее, почему это прямо не возложить на плечи менеджера?
V>2. Какова вероятность, что твой код не выкинут через месяц, за ненадобностью заказчику? Часто бувает, что какая-либо функциональность нужна только через 3 дня, а потом про нее забывают и забивают.
какой смысл для менеждера требовать подчинённых рвать мышцы седалища там, где можно протянуть, чтоб забыли?
V>>1. Насколько проблематичны для конторы будут те баги, что ты сделаешь? Возможно их исправление в последующем — это естественный процесс работы вашей конторы и за оное контора тоже деньги с заказчика.
C0s>что мешает сделать без багов, но взять с заказчика деньги на их "исправление"?
Это решение не уровня программиста — он просто не в курсе всех ньюансов проекта.
C0s>это же выгоднее, почему это прямо не возложить на плечи менеджера?
Потому, что твой менеджер может и не захотеть оное брать на свои плечи. Он пообешал начальству определенный срок и хочет быть весь шоколадный перед начальством. Или для данной функциональсти требуется хоть какая реализация, но не позже 3 дней (заказчику приперло, если заказчику понравиться он даст деньги на доработку и исправление багов, не всегда заказчик представляет точно, что он хочет). Или..., да еще можно придумывать кучу необходимостей — жизнь она все одно разнообразнее.
V>>2. Какова вероятность, что твой код не выкинут через месяц, за ненадобностью заказчику? Часто бувает, что какая-либо функциональность нужна только через 3 дня, а потом про нее забывают и забивают.
C0s>какой смысл для менеждера требовать подчинённых рвать мышцы седалища там, где можно протянуть, чтоб забыли?
Да потому, что начальник твоего менеджера очень хочет данное увидеть (пусть даже убедиться, что дальше оно не нужно, посмотреть на сделанное и забыть). Это тоже только как одна причина данного, реально причин может быть еще тысяча.
Здравствуйте, Pro100Oleh, Вы писали:
PO>Интересные ответы, всем спасибо, но хотелось бы так же услышать коментарии для немного другой ситуации
Без разницы...
Все вопросы, когда у одной стороны одно представление,
а у другой — соответственно другое, разрешаются общением.
Надо просто говорить с другой стороной.
Что тебе мешает подойти к тимлидеру и так сказать, что типа вот,
за 3 дня смогу только так, и в итоге это может вылится вот в это?
Ты его может быть убедишь, а может быть не убедишь.
Может быть убедишь, но он тебе приведет аргументы,
почему именно сейчас все же лучше сделать за 3 дня.
Ну и так далее... Вариантов развития может быть много, но все равно надо просто общаться...
Здравствуйте, peer, Вы писали:
P>Привет! P>Скажите как себя вести, когда руководством сроки даются нереальные малые, за которые есть возможность сделать только с кучей багов?
Нельзя идти на такие уступки
Не уважать свой труд значит не уважать себя
Более того если заставлять человека работь в таком режиме
у него со временем вообще отпадет желание работать
и потери времени от снижения эффективности вследствие такой политики
сведут на нет экономию времени
В результате в долгосрочной перспективе
не будет ни качественного продукта
не экономии времени
не коллектива у которого есть желание что-то делать
) поэтому рекомендую следующую литературу:
Не в МВ случайно работал?
