Director of Development в SMTP Inc.
  • 80-й (внеочередной) выпуск подкаста «Откровенно про IT карьеризм». Беседа с David Multer, CTO Waverley

    Проблема в том что практически не слышно что говорит сам David в общем шуме вокруг. Но в то же время он говорит достаточно интересно, что бы не пытаться его слушать :-)

  • 80-й (внеочередной) выпуск подкаста «Откровенно про IT карьеризм». Беседа с David Multer, CTO Waverley

    Сорри но реально очень мешает переводчик. Может это можно как то решить уровнем звука перевода (ну если он вообще нужен) ?

    Підтримав: AlekseyB Berezan
  • Современные офисные городки в парковой зоне — мечта или реальность?

    На мой скромный взгляд, проблема необходимости (неважно надуманной или реальной) близости размещения офиса в центре города связана с тем что есть непосредственный спрос от сотрудников. Несмотря на то что по всему миру существует и шириться тенденция жизни в регионах — в Украине IMHO все стремятся к крупным городам и жизни чем ближе к центру города тем лучше. Ну если не жить, то хотя бы на работу ездить. И никого не пугают многочасовые пробки и толкучки в общественном транспорте. Причин тому достаточно много: — плохие и проблемные транспортные развязки как за городами так и на их окраинах — инфраструктура (магазины, детские сады, школы, больницы и тп) зачастую не выдерживает критики — безопасность (далеко не везде есть своя охрана а вызов милиции из маленького участка может вылиться в отдельную историю для внуков) . Суммируя все это — очень похоже на идею внедрения townhouses в начале 2000х — бюджетное жилье обернулось элитным и не смогло конкурировать ни с эконом классом ни с бизнес... Так и стоят эти заброшенные строения незаселенные — ждут своего срока утилизации...

  • Рейтинг языков программирования, 1H2012

    Шикарный обзор! Спасибо!

  • О пользе и вреде детального планирования

    Ну денежные вопросы можем обсудить и за чашкой чая Ж-) Думаю что за фейсбук можно разориться и на большее... В общем — будет желание — мои контакты есть на сайте.

  • О пользе и вреде детального планирования

    Я ж не сказал «научу» Ж-) я сказал — покажу — а вы разве никогда не видели рывок штанги ? :-)

  • О пользе и вреде детального планирования

    Предлагаю по-работать вместе. Вы — напишете фейсбук а я — покажу как с наскока делать более сложные вещи. — это абсолютно серьезное предложение.

  • О пользе и вреде детального планирования

    Не «калил» я ни с форумов ни с доводов! Сам дошел. Все буквы в песне мой личный опыт. Сорри, конечно, за велосипед.... Что то весной наверное навеяло :-)

  • О пользе и вреде детального планирования

    Полностью согласен — иногда это просто бюрократия. Тему доверия попробую раскрыть в следующей статье Ж-)

  • To Be Agile Or Not To Be Agile?

    ОК Будь по Вашему :-) Это был T&M c фиксированной ценой. А как еще в аутсорсе посчитать стоимость проекта если не через затраты рабочего времени ? Ж-) Результат к сожалению не имеет унифицированной единицы измерения Ж-)

  • To Be Agile Or Not To Be Agile?

    ну дык и я ж о том же!!! — фиксированная ЦЕНА за проект. Ему все равно какой там план. Он хочет феррари красненькое за милион и все. И ему все равно что для этого будет делаться. А мен аурс на рейт это как это считается. Ну конечно плюс коммерческая накрутка но это — по факту себестоимость которую объявляют клиенту. То есть именно этот милион за феррари. В T&M себестоимость проекта никто не объявляет так как ее никто не знает и продают просто man hours без ограничений по итоговой СУММЕ за проект.

  • To Be Agile Or Not To Be Agile?

    а что ж это тогда ? man-hours умножить на рейт = сумма денег которая не изменяется т/е fixed price. Кто сказал что fixed price должен быть еще и fixed scope (кроме команды А)? или даже fixed task list Ж-)

  • To Be Agile Or Not To Be Agile?

    клиент заплатил ровно столько сколько договаривались не больше и не меньше и команда отработала ровно то кол-во часов которое было уговорено. Так что по факту никто в убытке не остался. Ж-) вот в чем хитрость то :-)

  • To Be Agile Or Not To Be Agile?

    Ну я так и написал — оба проекта изначально подписывались как fixed price. Оба проекта соответственно оценивались, торговались на основе первой оценки и сроках (оба были 4 месяца) и тп. О Т&M речь не идет.

  • To Be Agile Or Not To Be Agile?

    предлагаю оставить это под покровом тайны :-) хотя странно было бы для меня в таком случае писать эту статью :-)

  • To Be Agile Or Not To Be Agile?

    ну лично я, когда работал по ватерфолу, всегда подписывал project plan с design spec и четко указанным скопом. Может сейчас это изменилось...

  • To Be Agile Or Not To Be Agile?

    ну однозначно всего в статье не опишешь :-) соглашусь пожалуй что слово agile в заголовке действительно сыграло плохую роль. Тут больше имелась ввиду именно гибкость что в целом часто и понимается под agile :-)

  • To Be Agile Or Not To Be Agile?

    потому что в первом случае — кроме цены была подписана спецификация (те scope) и изменения пошли как change request, а во втором случае scope остался не зафиксированным (что конечно с точки зрения классического управления проектами является преступлением :-)) фиксировалась только скорость качество команды.

  • To Be Agile Or Not To Be Agile?

    Ну если это поможет могу поклясться на крови. Или привести свидетелей что так оно и было :-). Хотя вера — это конечно — штука тонкая :-)

  • To Be Agile Or Not To Be Agile?

    Чтоб закрыть тему — оба проекта начинались именно как fixed price. Разница только в подходе «фиксирования» скопа. Считались men-hours на рейт у обоих. Так что пусть меняет что хочет главное чтоб не вылезло за пределы договоренной суммы. А потом — у Team A пошел change request Managment а Team B просто сразу начали выстраивать приоритеты изначально и продолжали в том же духе.

← Сtrl 12 Ctrl →