Разработчик, agile-коуч и сертифицированный scrum-тренер (CST) в krivitsky.com
  • «Аутсорсинг головного мозга». Или всё-таки можно научиться совмещать гибкую разработку и fixed-price?

    то, что скрам не даёт решений — это не проблема.

    если бы он их давал для каких-то проектных контекстов, то по определению они бы не подходили для всех остальных.

  • «Аутсорсинг головного мозга». Или всё-таки можно научиться совмещать гибкую разработку и fixed-price?

    Аутсорс и продуктовка — это та же заказная разработка, только заказчик разный

    уважаемый Maksym, в моём определении:

    в заказной разработке продуктом владеет заказчик (не вендор) — кто-то по ту сторону контракта. в такой системе есть контрактуальная игра между business клиента — IT вендора (к примеру). если вы на стороне вендора, то вы делаете проект. для бизнеса же — это продукт.

  • «Аутсорсинг головного мозга». Или всё-таки можно научиться совмещать гибкую разработку и fixed-price?

    если вы не применяете что-то в чистом виде, то зачем это вообще как-то называть тогда?

  • «Аутсорсинг головного мозга». Или всё-таки можно научиться совмещать гибкую разработку и fixed-price?

    не видел хороших реализаций. как у коммунизма.

  • «Аутсорсинг головного мозга». Или всё-таки можно научиться совмещать гибкую разработку и fixed-price?

    «по-латыни» — вроде через дефиз.

  • «Аутсорсинг головного мозга». Или всё-таки можно научиться совмещать гибкую разработку и fixed-price?

    пришлось зайти на википедию (латынью владею не в совершенстве): en.wikipedia.org/...o_Danaos_et_dona_ferentes

    к тому же «gift» — по-немецки «яд».

    я не писал о presale, потому что не имею с этим реального опыта, которым бы стоило делиться. пишу о том, что видел, во что верю. в presale не верю. так как любые пре-активности — это дутьё губ и вытягивание данных из воздуха.

    к тому же, по моему опыту — у многих менеджеров, невольно страдающих от описываемого недуга (заглавие статьи) зачастую нет политической силы влиять на пресейл. поэтому в статье я сфокусировался на аспектах управлением проектов пост-фактум составленного договора, каким бы он нереальным ни был.

    «прокидывать клиентов» я не призывал. вы, Владимир, за моими словами видели, похоже, проекции своих мыслей (что ж, это не грех, у нас у всех таким образом работает сознание). если вы внимательно (помедитировав) вчитаетесь в суть моих посланий в статье, то заметите, что я призываю работать с клиентом за ради его и вашего блага. это по определению — противоположное действие от «прокидывания».

    уж не знаю, как это сказать по латыни.

    Підтримав: Volodymyr Yatsevsky
  • «Аутсорсинг головного мозга». Или всё-таки можно научиться совмещать гибкую разработку и fixed-price?

    я согласен — не все клиенты одинаково полезны для вашего бизнеса. в долгосрочной перспективе имеется в виду. поэтому на карту кроме краткосрочных интересов по получению контракта нужно ставить «здоровье» вашей компании. случаи ухода персонала из-за «неадкватности клиента» не редки.

    но на моём опыты (и мой врождённый идеализм меня тут поддерживает) — правильная работа с клиентом посредством «реального менеджемента» (как я описал в статье) сильно занижает негативное влияние клиента на ваши с ним отношения.

    Підтримав: Dmytro Lapshyn
  • «Аутсорсинг головного мозга». Или всё-таки можно научиться совмещать гибкую разработку и fixed-price?

    А вот и ещё один комментарий с клона статьи на www.krivitsky.com

    Beaver Green (Wednesday, 23 November 2016 15:29)

    На ДОУ меня коментить не пускают — спрошу тут. Надеюсь ответ напишите там.
    Вы правильно уловили стиль менеджмента не fixed-price проекта в типичном аутсорсе:
    «Если у вас в проекте не ограничены средства, зачем тогда вообще что-то менеджетить?»
    Именно такое я видел на 80% «бесконечных» проектов где клиент платит за человеко-часы.
    А вот на редких fixed-price проектах все разительно отличалось в лучшую сторону! Поскольку клиент заплатит только за результат — то есть смысл работать эффективно и качественно что бы к релизу не утонуть в багах.
    Один вопрос меня постоянно смущал: если проект fixed-price и клиент платит за результат, а не за попа-часы то не логично ли что и команде то же нужно платить за результат — а не заставлять отсиживать рабочие часы за фиксированную ставку (как в большинстве ИТ компаний)?

    Підтримав: Ярослав Успенский
  • 75-й выпуск подкаста «Откровенно про IT карьеризм». Беседа с Алексеем Кривицким, первым Agile Coach в Украине

    точно, яркая рекламка в начале и полчаса бурчания

  • 75-й выпуск подкаста «Откровенно про IT карьеризм». Беседа с Алексеем Кривицким, первым Agile Coach в Украине

    даже не знаю, слушать или нет.

    пожалуй, не буду :)

    я обычно намного приятней в ближнем бою, чем на записях, тем более на аудио.

    Підтримав: Julia Savinkova
  • 75-й выпуск подкаста «Откровенно про IT карьеризм». Беседа с Алексеем Кривицким, первым Agile Coach в Украине

    хм, это я так сказал в подкасте? ну, значит, я лошара :)

    Підтримали: Alexey Gapchenko, Mykhailo Marchenko
  • «Недокоммуникация» как один из признаков украинского аутсорсинга

    В статье озвучены важные проблемы. Их можно решать по-разному. Одни решения лечат следствия, другие — причины. Третьи же только усиливают проблемы...

    К примеру, качественный репортинг можно делать разными способами: можно оповещать заказчика о технических проблемах, можно делать демонстрации фич, можно отсылать имейл с новостями по проекту, можно звать на daily meeting... Но что из этого лечит причину, а что лишь ее вуалирует? Причины у необходимости репортить обычно такие: недоверие заказчика к команде и тенденция к тотальному контролю. Увы...

    Микроменеджмент со стороны заказчика обычно только усиливает его паранойю — чем больше он контролирует и чем больше видит, тем больше хочет вмешиваться и влиять.

    Но с другой стороны: если заказчик получает обещанные ему фичи во время и с адекватным качеством, будет ли он микроменеджить на уровне задач и работников? Или он доверится команде и теперь посвятит свое ценное время более важным вещам — работе с пользователями, заинтересованными лицами и scope-management.

    Я бы посоветовал — учиться разделять внутреннюю кухню команды (технические вопросы) от продуктовых (бизнес) вопросов, которые в компетенции заказчика. Большинство проблем на моем опыта возникают именно из-за того, что заказчик сидит на двух стульях.

    Мои советы:

    1) Сделайте прогресс видимым
    a) проводите регулярные демонстрации фич и версий продукта (не реже, чем раз в две недели)
    б) заведите такой тул, который разграничивал бы кухню от клиентов — тул, в котором заказчику был бы виден статус по фичам, без деталей о задачах и работниках

    2) Научите заказчика управлять изменениями и скоупом
    а) научите заказчика концепции релизов с фиксированным временем и плавающим скоупом, в который вы вместе будете целиться
    б) научите заказчика визуализировать прогноз по скоупу, который попадает в релиз (инструмент release burndown chart)
    в) регулярно садитесь с заказчиком для уменьшения и уточнения скоупа работ в релизе (хорошее время для этого демонстрация версии)

    3) Делайте все, чтобы заказчик ездил к вам. Так часто, как это возможно
    а) уточняйте цели и видение проекта
    б) во время его приездов планируйте релизы
    в) обсуждайте улучшения процесса

    Эти советы одинаковы как для аутсорсинговых команд, так и для стартаперов.

    Підтримали: Beaver Green, Vadim Osovets
  • Новости раздела Колумнисты: RSS, бан для авторов and more

    Вот что я об этом думаю на самом деле. ТРОЛЛИНГ ЭТО БОЛЕЗНЬ, БЕЗКУЛЬТУРИЕ И ТЕРРОРИЗМ.

    www.krivitsky.com/...ll-breding-or-act-of.html

  • Новости раздела Колумнисты: RSS, бан для авторов and more

    запрет решает часть проблем. это как борьба с терроризмом. не пускают на борт самолета со взрывчаткой — банят.

  • Новости раздела Колумнисты: RSS, бан для авторов and more

    «критика должны быть конструктивной» — факт. неконструктив — банить.

  • Новости раздела Колумнисты: RSS, бан для авторов and more

    Согласен, Сережа — все верно

    Не нашел фичи удаления коммента на доу... Не говоря уже о всем том, что я предложил ниже.

  • Новости раздела Колумнисты: RSS, бан для авторов and more

    Мое мнение: в Украине общаться не умеют. Это Азия.

    Такие комменты, какие прочтешь здесь или скажем на корреспонденте, я думаю в Европе бы никто бы и не подумал писать. Там правило: «не нравится — промолчи» (Дания) или «не нравится — скажи лично» (Швейцария).

    У нас же — «подумай как обосрать и сделай это публично». К тому же акт и результат обосрания теперь носит красивое название «троллинг», а сам активист действия именуется ярким на славянское ухо словом «троль».

    Это лирика. Теперь по сути. Предлагаю:
    1. ввести флаги на комменты
    2. флаги имеют как минимум 3 типа: spam, offtop, trolling
    3. флаги могут ставится кем-угодно
    4. по накоплению 1-3 флагов на коммент, коммент скрывается
    4.5 (опциональный шаг) группа модераторов от доу (волонтеры как вариант) просматривают отфлаганные комменты и проверяют все ли честно
    5. автор коммента получает имейл с предупреждением
    6. за накопление предупреждений автор коммента переводится в readonly-режим на время.
    7. в следующий раз время readonly режим удваивается, и автору достаточно одного флага, чтобы туда уйти.

    Конструктивно общение в Украине требует каркасов, иначе ему не судьба случиться. Он, правда, не должен быть таким сложным как на хабре, но он нужен.

    Я это пишу, и уже готов к троллингу... А жаль, но все еще может быть по-другому.

    Підтримав: Max Ischenko
  • Education 3.0

    делаем — что можем. а как вы видете новое образование?

    agile circles — эксперимент. в мае опросим участников апрельских кругов — пусть расскажут как там было: обертка или же по-другому.

  • Education 3.0

    друзья, вы со мной знакомы лично? на чем основаны ваши предубеждения?

  • Education 3.0

    привет, модулей пока что четыре. будет больше. в мае стартуем «работу с заказчиками и требованиями». а зачем вам последний? )

← Сtrl 123 Ctrl →