Здравствуйте, peer, Вы писали:
P>Привет! P>Скажите как себя вести, когда руководством сроки даются нереальные малые, за которые есть возможность сделать только с кучей багов?
Так и сказать им об этом.
Пусть они решают, что им важнее: сроки или качество.
Это в общем-то прямая задача начальства, принимать подобные решения.
Программист же обязать предоставить информацию, которой он владеет,
чтобы решение было принято осознанно.
P>Скажите как себя вести, когда руководством сроки даются нереальные малые, за которые есть возможность сделать только с кучей багов?
Я в таких случаях говорю что все будет пучком и вселяю оптимизм А потом что получилось то получилось: развожу руками "ну не шмогла я"
Как я понял успеем мы или нет никого не волнует, заказ то все равно берут
Здравствуйте, Kubyshev Andrey, Вы писали:
P>>Скажите как себя вести, когда руководством сроки даются нереальные малые, за которые есть возможность сделать только с кучей багов?
KA>Я в таких случаях говорю что все будет пучком и вселяю оптимизм А потом что получилось то получилось: развожу руками "ну не шмогла я"
Это то, что называется непрофессионализмом.
Типа берусь за все в любые сроки, за последствия не отвечаю, и вообще после меня хоть потоп...
Если еще и начальники такие же, то отставание в 10 раз выясняется в день сдачи проекта.
Такое увы и в самом деле бывает...
Здравствуйте, peer, Вы писали:
P>Привет! P>Скажите как себя вести, когда руководством сроки даются нереальные малые, за которые есть возможность сделать только с кучей багов?
С кучей каких багов? Если архитектурных, то и фиг с ними — отрефакторишь.
Здравствуйте, Kubyshev Andrey, Вы писали:
B>>Это то, что называется непрофессионализмом.
KA>Ты б лучше у меня учился чтоооле..
1) Сколько времени уходит на воду (сходить до колонки, спипятить, заварить)
2) Сколько времени уходит на молоко (послать утром в стадо, поймать вечером, подоить)
3) Сколько времени уходит на то, чтобы понять — Несквик проще.
Здравствуйте, peer, Вы писали:
P>Привет! P>Скажите как себя вести, когда руководством сроки даются нереальные малые, за которые есть возможность сделать только с кучей багов?
С кучей багов — вряд ли будет засчитано как сделанное.
В нормальном коллективе: сказать, за сколько времени я готов эту работу выполнить, так, чтобы получилось надёжно, и на результат бы можно было положиться. Если хотят быстрее — предложить на выбор несколько вариантов сокращения функциональности (и соответственно увеличения скорости).
В серпентарии: любимые работники (начальства), не успев к сроку, "переключаются на более важные задачи", спихивая глючный недоделанный кусок обычным работникам. Обычные работники, доделывающие этот кусок, и особенно — находящиеся в подчинении у любимых работников (и ими оцениваемые), выставляются виноватыми, и, если других заслуг нет, получают пинком под зад. Попытки как-либо вести себя — скорее приведут к получению репутации нелояльного. Остаётся или оказаться любимым работником, имеющим право выбирать себе задачи, или решать проблему за свой счёт (переработки, к которым, собственно, и склоняют, назначая нереальные сроки).
Здравствуйте, peer, Вы писали:
P>Привет! P>Скажите как себя вести, когда руководством сроки даются нереальные малые, за которые есть возможность сделать только с кучей багов?
Напиши письмо начальству (непосредственному и выше) о том, что для выполнения работы нужны такие то сроки либо дополнительные разработчики. Что к такому то сроку возможно получить то-то и то-то. И все. Главное не подписываться под тем, что к назначенному сроку все будет готово
Здравствуйте, peer, Вы писали:
P>Скажите как себя вести, когда руководством сроки даются нереальные малые, за которые есть возможность сделать только с кучей багов?
часто там где встаёт такой вопрос, обычно присутствует полная неразбериха с требованиями и нежелание потратить время на документирование шагов и решений
из-за этого сроки всё равно будут сбиты, и главное в такой ситуации суметь одновременно как выразить согласие на "сделать", так и в процессе политически извернуться так, чтобы когда выявится несогласованность в требованиях, виноваты были именно те, кто что-то там не согласовал или недодокументировал, а не ты, как медленно (но нормально) программирующий. в частности, полезно про любую несогласованность или непонянтность в требованиях слать начальнику письма с вопросами — пусть у начальника, который взял на себя ответственность "порвать, но сделать", болит голова, как найти ответы на твои вопросы
Здравствуйте, Kubyshev Andrey, Вы писали:
P>>Скажите как себя вести, когда руководством сроки даются нереальные малые, за которые есть возможность сделать только с кучей багов?
KA>Я в таких случаях говорю что все будет пучком и вселяю оптимизм А потом что получилось то получилось: развожу руками "ну не шмогла я" KA>Как я понял успеем мы или нет никого не волнует, заказ то все равно берут
А начальство может все беды свалить на тебя, при этом разводя руками перед их начальством — "А он нам обещал".
Может даже показательно уволить, всякое бывает. Лучше сразу поставить в известность, заявить о проблемах не по факту получения, а по факту осознания Может даже людей дополнительных выделят. Проблема то реализации это общая проблема, а не конкретного разработчика. Спрашивать будут со всех
А если непосредственное начальство не шевелится, и стоит на своем — проблему эскалируем. Может непосредственное начальство малясь неадекватно
Здравствуйте, Дмитрий В, Вы писали:
P>>Привет! P>>Скажите как себя вести, когда руководством сроки даются нереальные малые, за которые есть возможность сделать только с кучей багов? ДВ>Напиши письмо начальству (непосредственному и выше) о том, что для выполнения работы нужны такие то сроки либо дополнительные разработчики. Что к такому то сроку возможно получить то-то и то-то. И все. Главное не подписываться под тем, что к назначенному сроку все будет готово
отказываться подписывать чревато неприятностями — это дает руководству лишний повод руководству пожаловаться на тебя более высокому руководству
Другое дело если подписать предоставленные сроки, но с обязательной отметкой о том что ты оцениваешь реальные сроки иначе и привести свою оценку сроков. Думаю не трудно догадаться чьи сроки окажутся реальными Однако если указал свои сроки, будь готов любыми способами вложиться в них.
Если ты не вложился в сроки указанные руководством это вина руководства, а если не вложился в сроки указанные тобой — то это уже твоя вина.
Здравствуйте, Pro100Oleh, Вы писали:
PO>Интересные ответы, всем спасибо, но хотелось бы так же услышать коментарии для немного другой ситуации
Без разницы...
Все вопросы, когда у одной стороны одно представление,
а у другой — соответственно другое, разрешаются общением.
Надо просто говорить с другой стороной.
Что тебе мешает подойти к тимлидеру и так сказать, что типа вот,
за 3 дня смогу только так, и в итоге это может вылится вот в это?
Ты его может быть убедишь, а может быть не убедишь.
Может быть убедишь, но он тебе приведет аргументы,
почему именно сейчас все же лучше сделать за 3 дня.
Ну и так далее... Вариантов развития может быть много, но все равно надо просто общаться...
Здравствуйте, peer, Вы писали:
P>Привет! P>Скажите как себя вести, когда руководством сроки даются нереальные малые, за которые есть возможность сделать только с кучей багов?
Нельзя идти на такие уступки
Не уважать свой труд значит не уважать себя
Более того если заставлять человека работь в таком режиме
у него со временем вообще отпадет желание работать
и потери времени от снижения эффективности вследствие такой политики
сведут на нет экономию времени
В результате в долгосрочной перспективе
не будет ни качественного продукта
не экономии времени
не коллектива у которого есть желание что-то делать
Обычно лучше пожертвовать какой-то функциональностью (согласуется с заказчиком — т.е. начальством), оставшуюся сделать качественной, без багов и легко расширяемой до требуемой и более..
Здравствуйте, peer, Вы писали:
P>Привет! P>Скажите как себя вести, когда руководством сроки даются нереальные малые, за которые есть возможность сделать только с кучей багов?
Оформи задание на бумаге вместе с таблицей где в отдельных колонках указаны сроки указанные руководством, и отдельной колонкой где укажи сроки которые ты сам оцениваешь.
После одного-двух раз руководство наверняка откажется само устанавливать сроки, т.к. они всегда будут заведомо неправильными в отличие от твоих, что внешне будет выглядеть как некомпетентность руководства
_M_>Оформи задание на бумаге вместе с таблицей где в отдельных колонках указаны сроки указанные руководством, и отдельной колонкой где укажи сроки которые ты сам оцениваешь. _M_>После одного-двух раз руководство наверняка откажется само устанавливать сроки, т.к. они всегда будут заведомо неправильными в отличие от твоих, что внешне будет выглядеть как некомпетентность руководства
если руководство умное, то подписывать такую бумагу оно не станет и попросит оформить бумагу только с твоими оценками времени
Здравствуйте, _Morpheus_, Вы писали:
_M_>Другое дело если подписать предоставленные сроки, но с обязательной отметкой о том что ты оцениваешь реальные сроки иначе и привести свою оценку сроков. Думаю не трудно догадаться чьи сроки окажутся реальными
в описанной ситуации налицо присутствие чего-то нездорового. думаю, в таком разе нереальными окажутся оба варианта сроков
Здравствуйте, peer, Вы писали:
P>Привет! P>Скажите как себя вести, когда руководством сроки даются нереальные малые, за которые есть возможность сделать только с кучей багов?
Если речь идёт о программе, которую нужно сделать за 1,5 часа, то выполнить
Если идёт речь о большом проекте, объяснить руководству, что ошибки в программе накопятся и всё равно затормозят работу, да, возможно, ещё больше, чем если сразу всё делать качественно
Здравствуйте, _Morpheus_, Вы писали:
_M_>Здравствуйте, peer, Вы писали:
P>>Привет! P>>Скажите как себя вести, когда руководством сроки даются нереальные малые, за которые есть возможность сделать только с кучей багов?
_M_>Оформи задание на бумаге вместе с таблицей где в отдельных колонках указаны сроки указанные руководством, и отдельной колонкой где укажи сроки которые ты сам оцениваешь. _M_>После одного-двух раз руководство наверняка откажется само устанавливать сроки, т.к. они всегда будут заведомо неправильными в отличие от твоих, что внешне будет выглядеть как некомпетентность руководства
Гы, я видел, когда оценка времени, явно заниженная, руководством ещё занижалось, потом, когда не успевали, опять требовали занизить и т.д. Т.е. не поможет это, если руководство совсем ничего не понимает
ДВ>А начальство может все беды свалить на тебя, при этом разводя руками перед их начальством — "А он нам обещал". ДВ>Может даже показательно уволить, всякое бывает. Лучше сразу поставить в известность, заявить о проблемах не по факту получения, а по факту осознания Может даже людей дополнительных выделят. Проблема то реализации это общая проблема, а не конкретного разработчика. Спрашивать будут со всех ДВ>А если непосредственное начальство не шевелится, и стоит на своем — проблему эскалируем. Может непосредственное начальство малясь неадекватно
Да как вы не понимаете, что все равно начальтсво свалит на исполнителей, елки палки, детский сад. Разумеется, если меня СПРАШИВАЮТ о сроках, то я адекватно постараюсь оценить и всё такое. Но в ситуации топиккастера все по другому!
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>какой смысл для менеждера требовать подчинённых рвать мышцы седалища там, где можно протянуть, чтоб забыли?
Да потому, что начальник твоего менеджера очень хочет данное увидеть (пусть даже убедиться, что дальше оно не нужно, посмотреть на сделанное и забыть). Это тоже только как одна причина данного, реально причин может быть еще тысяча.
А потом что получилось то получилось: развожу руками "ну не шмогла я" 
