(function() { var count, root; root = $('.comment[data-id="3965"]'); root.find(".comment").remove(); root.append("
\n
\n<\/a>\n
\n\"Missing-male\"\n<\/div>\n
\n
\nKesha<\/a>\n
\n\n<\/div>\n
\n
7 February 2009, 08:02<\/a>\n<\/time>\n↑<\/span>\n<\/div>\n
\n

Ответы на эти вопросы мне нужны для личного пользования. Чтобы было вечерком с пивом над чем поразмышлять.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n

\n
\n<\/a>\n
\n\"Missing-male\"\n<\/div>\n
\n
\nlyonelll<\/a>\n
\n– BD в SoftSwiss\n<\/div>\n
\n
18 February 2009, 15:44<\/a>\n<\/time>\n↑<\/span>\n<\/div>\n
\n

Почитайте выше про недоэстимейты и всё АСАПом. \n<\/p>

Ну или сайты компаний покурить, как у кого, например, с контролем качества.. \n<\/p>

Крупная компания IBA: http://belarus.iba.by/iba_web/main.nsf/about/en.quality.html<\/a>\n<\/p>

Компания среднего размера Science Soft: http://www.scnsoft.com/SoftwareQATesting.html<\/a>\n<\/p>

Itransition: http://www.itransition.com/work/software-development-quality.php<\/a>\n<\/p>

Как то скромно для такого размера, что ли? <\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n<\/a>\n
\n\"Missing-male\"\n<\/div>\n
\n
\nKesha<\/a>\n
\n\n<\/div>\n
\n
25 February 2009, 09:01<\/a>\n<\/time>\n↑<\/span>\n<\/div>\n
\n\n+6\n<\/strong>\n<\/div>\n
\n

Про недоэстимыйты мне читать не надо :) Я поработал в Итранзишене достаточно, чтобы знать ситуацию по проектам и общую статистику по компании.\n<\/p>

Очень многое здесь зависит от бизнес-модели компании. Вот возьмём, например, контроль качества. Имеет ли смысл разворачивать на проекте в 3 девелопера на 3 месяца процесс по ISO9001 или еще какому-нибудь промышленному стандарту? Вряд ли. Это будет слишком большой overkill. Т.к. почти все проекты были такого масштаба (и за соответствующие деньги), то обучать людей таким процессам и потом их ставить, на мой взгляд было экономически неразумно. Поэтому общий \"размер [компании] не имеет значения\" в данном конкретном случае. Лично мы на своем небольшом проекте (7-8) человек поставили свой процесс контроля качества - он был не ISO, не CMMI, а именно такой, который был необходим.\n<\/p>

Как обстоят дела на IBA и Science Soft с этим, я по сайтам судить не берусь. Возможно, у них до сих пор есть отдельные большие проекты, где массивные процессы контроля качества имеют смысл или являются обязательным требованием заказчика (например, довольно много специфического ПО обязано разрабатываться по производственным стандартам).\n<\/p>

Плавно перейдем к оценкам и АСАПам. Довольно точную оценку можно дать при наличии следующих условий (ИМХО):\n<\/p>

1. Есть хорошая база истории оценок проектов определенного типа (ни разу не видел чтобы у кого-то хватило терпения это делать) - это идеальный вариант с точки зрения теории оценивания.\n<\/p>

2. Наличие эксперта(ов) в соотвествующих техническом и бизнес домене. При постоянной ротации обеих составляющих проектов таких экспертов маловато.\n<\/p>

3. Есть много времени на дополнительные исследования и устранение неизвестных. Концепция оценивания проектов в Итре времени давала не очень много.\n<\/p>

4. Итеративный подход к оценке (после первой фазы, когда набирается опыт в домене, вторая фаза оценивается точнее и т.д.). ИМХО, самый оптимальный способ, но, к сожалению, заказчики хотят знать весь бюджет сразу и не соглашаются на пошаговый процесс.\n<\/p>

Часто проблема решается двумя путями: закладыванием рисков (в реальности - домножение оценки на N, где N берётся из опыта) или хорошим лобби компании при выборе заказчиком вендора (в этом случае оценка должна быть просто вменяемой и с запасом, чтобы уж точно не завалить сроки и потерять доверие заказчика). В Итре, опять же из-за бизнес-модели, лобби не имело место быть почти на всех проектах, а домножать - это значит терять конкурентность оценки в тендере. Тут лучше недооценить и делать пыхтя, чем переоценить и остаться без проекта.\n<\/p>

Сам оценивал около 10 проектов... Где перестраховывался, часто проигрывали тендер. Несколько штук выиграли с вполне адектватной оценкой - коллеги, вроде, после этого меня не били ногами :)\n<\/p>

В моей текущей компании методы контроля качества и оценки варьируются заметно от проекта к проекту. В более молодых проектах (не более 3-х лет) или инновационных оценки оставляют желать лучшего, в более старых и устоявшихся проектах (5-12 лет) вроде всё более чётко, хотя сроки всё равно срываются и народ сидит по выходным и поздними вечерами.\n<\/p>

Так что, я предпочитаю действовать в зависимости от текущей ситуации и полагаться на свои силы и умения, а не на процессы глобальные для компании. Чего и Вам желаю :)<\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n<\/a>\n
\n\"Missing\"\n<\/div>\n
\n
\nVschrzzz<\/a>\n
\n– глупый кодер в Itransition\n<\/div>\n
\n
28 February 2009, 19:57<\/a>\n<\/time>\n↑<\/span>\n<\/div>\n
\n

А можно поподробнее про АСАПы?\n<\/p>

Значиццо, и в Itransition, и в \"моей [Kesha\'вской] текущей компании\" бизнес-стратегия требует не закладывания рисков и недоэстимейтов с целью выигрывания тендеров. Недоэстимейты превращаются в овертайм. Сотрудники пытаются удовлетворить клиента и проводят много времени в компании столь ценимых коллег: вечера, поздние вечера, выходные, потом ещё вечера.\n<\/p>

Возникает вопрос: как решается вопрос с перерасходом ресурсов?\n<\/p>

Сейлс звонит заказчику, демонически хохочет в трубку и заявляет \"Мы вас обманули! Ваш проект обойдётся вам дороже!\" ?\n<\/p>

С лопухнувшегося эстиматора снимают деньги, и раздают девелоперу, нуждающемуся в полторашной ставке оплаты овертаймов?\n<\/p>

Девелоперы с мрачными лицами и мыслями \"Чёртовы неоплачиваемые овертаймы\" расходятся по домам, а потом им выставляют счета за лишнее нажжённое ночью электричество?\n<\/p>

Плиз, по обеим компаниям. Ну или по той, в которой и оценивал эти десять проектов.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n<\/a>\n
\n\"Missing-male\"\n<\/div>\n
\n
\nKesha<\/a>\n
\n\n<\/div>\n
\n
28 February 2009, 20:26<\/a>\n<\/time>\n↑<\/span>\n<\/div>\n
\n\n+1\n<\/strong>\n<\/div>\n
\n

Нда. Интересные у вас варианты...\n<\/p>

Мой нынешний работодатель не является аутсорсером, а производит и продает свои продукты. Так что если здесь неправильно оценился проект, то решают это стандартными способами: а) работают в овертайм, б) урезают функционал, в) переносят сроки выпуска продукта.\n<\/p>

Что же до аутсорсинговых компаний, то здесь по-моему тоже всё стандартно. Развитие событий обычно зависит от типа контракта и его условий. Если это жёсткий fixed price проект с penalty за срыв сроков, то вендор будет доделывать его за свой счёт. Как он будет оплачивать это непосредственным исполнителям зависит от финансового положения и совести топ-менеджмента.\n<\/p>

Если же это time & materials, то тут обычно проджект менеджер пытается втереть заказчику лишние часы как нечто абсолютно необходимое и само собой разумеющееся. \n<\/p>

Вы тут справделиво подняли тему обратной связи по оценке проекта. Так вот конкретно в Итре она не была формализована и это, конечно, было зря. Эффективность оценщика оценивалась обычно по проценту выигранных проектов, а точность самой оценки никак не учитывалась. Наверное, если оценка оказывалась ужасающе неточно, то оценщику уже меньше доверяли. Однако я таких случаев не знаю и обобщать не решусь.\n<\/p>

В большом проценте случаев, оценщик вообще не участвует в реализации проекта, что снимает с него почти всю ответственность (это глупо, плохо, но так почему-то происходило) Если не ошибаюсь, я ни разу не делал проект, который оценивал. Но всегда старался держать связь с прожект менеджером и выяснять, где были допущены ошибки в оценке.\n<\/p>

Надеюсь, я ответил на Ваши вопросы.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n<\/div>\n\n<\/div>\n\n<\/div>\n\n"); root.find(".comment-show-replies").remove(); count = $(".comments-list").find(".comment").size(); $(".loading-panel .object-count-inside").text(count); }).call(this);

Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.