• Почему у нас все через %опу – получи ответ от экспертов!

    Posted on February 12th, 2009 Александр Орлов 14 comments

    Коллеги, честно говоря, результаты голосования по методологиям меня немного того – шокировали. Ну, то есть я догадывался, что “отечественные” методологии (“Как получится” и “Через %опу”) наберут какое-то количество голосов, но не подозревал, что столько. Даже если сделать скидку на очевидный флэшмоб в среду, когда количество голосов кандидата “Через %опу” подскочило с 25% до 40% – все равно, что-то не ладно в Датском королевстве…

    Ситуация требует срочной реакции. Это не совсем тематика сайта Happy PM (у нас тут больше про человеческие аспекты), но… но нельзя без слез смотреть на эту картину. :)

    Короче, предложение – мы делаем круглый стол российских экспертов по вопросам методологий. Где они отвечают на ваши животрепещущие вопросы.

    Вы – описываете свою ситуацию и/или задаете вопросы в комментариях к этому посту или на info@happy-pm.com, если не хотите публичности. Я надеюсь, что все вы люди ответственные и думающие, то есть можете изложить свои мысли и видение проблем, их причин и последствий.

    • Почему все делается как получится?
    • Что у вас не в порядке с процессом?
    • Почему ситуация не меняется?
    • …

    Экспертами выступят:

    Приблизительная дата круглого стола – 24 февраля. Запись будет выложена в открытый доступ. (Вполне возможно, что это будет формат вебинара, но обещать не стану.)

    Update: таки вебинара не будет. Будет аудиозапись. Поэтому вопросы лучше задавать заранее здесь или засылать на почту.

    Update 2: Мероприятие перенесено на вечер 25-го февраля.

    События, Эксперты
     

    14 responses to “Почему у нас все через %опу – получи ответ от экспертов!”

    1. Константин Иванов February 12th, 2009 at 20:45

      У меня ситуация такая.. Сотрудников 2 человека (+ я) и короткие сроки проектов (1-2 недели). Документация не по одному из проектов не ведется.. К каждому проекту я подхожу индивидуально и каких то конкретных шагов нет. Кое как удается культивировать идею о технических заданиях (про это ранее вообще не слыхали и все задачи ставились в стиле “хочу вот такую вот штучку”), + удалось хоть как то формализовать процесс разработки программ (поделить работы на проектирование, рисование дизайна, кодирование, тестирование, внедрение и выстроить в правильном порядке), опять же до этого в порядке вещей было сначала все сделать а когда уже все почти готово сказать – а что то тут с дизайном не так и нада бы переделать… Это хотя бы позволило уменьшить сроки проектов и избавться (пока что) от “мертвых” проектов..
      Но сроки становятся короче, задания сложнее и иногда получается путаница.. Возможно ли тут использовать какую то методологию? (я в общем то читал MSF, PM BOK , Scrum, но что то сложно понять как это все реально применить).. А и ещё 1 немаловажный я думаю факт – все проекты ведутся для внутреннего использования в компании (она большая и проектов достаточно много :) )

    2. 7ft February 14th, 2009 at 00:27

      В субботу не было флеш-моба. Это абсолютно объективные оценки группы специалистов.

    3. 7ft February 14th, 2009 at 00:30

      Прошу прощенья, в среду…

    4. Александр Орлов February 14th, 2009 at 15:14

      Ок. Специалисты, напишете, что у вас там такое и почему и как все через это место?

    5. 7ft February 15th, 2009 at 02:02

      По поводу “группы специалистов”.

      Не буду отвечать за всех проголосовавших в среду, но некоторых из них я знаю. В состав входят: несколько аналитиков, руководители проектов, пара ведущих программистов. Работают в различных компаниях. Участвуют в различных проектах, от медицины до управления имуществом. Единственное, что объединяет все наши проекты, это отсутствие нацеленности на одного заказчика. Цель проектов – разработка “типового решения”.

      По поводу “что там у нас происходит”.

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

      Можно искусствено притягивать такой проект к общеизвестным методологиям, и увидеть, например, итерации. Каждая такая итерация – это внедрение решения на конкретном этапе. Однако суть такой итерации совершенно другая. В нашем случае, каждый новый виток не обязательно дополняет предыдущий, а зачастую и вовсе откатывает. Учитывая размер такой итерации, можно представить масштаб трагедии.

      Так что же нам все-таки мешает? Или что не помогает? Необходимо,в первую очередь осознавать, что основным наследием, переходящим от одной итерации к другой, является ни в коем случае не код, не функционал, не технология, и даже не методология. Основная полезная масса – это знания, как правило не свойственные обычным разработчикам ПО и их руководителям. К таким знаниям можно отнести анализ рынка, управление экономическими рисками, различные нормативно-правовые аспекты разработки. Их то как раз всегда и не хватает (не хватает знаний, аспектов-то как раз много). Поэтому какие бы методологии не применялись для разработки, получается “как всегда”. А если методология ничего не решает, значит она не работает. Так что же нам не помогает? Наверное, отсутствие специалистов в упомянутых категориях знаний применительно к разработке ПО…

      По поводу “почему через ж%пу”.

      Выбор встал между тремя вариантами “через ж%пу”, “как получится”, “другое”. Здесь буду говорить только о своих собственных рассуждениях. “Другое” мне сразу не понравилось, не выражает ситуации в моем проекте). Осталось “как получится” и “через ж%пу”. “Через ж%пу” мне показалось более литературным што-ли. Опять же вспомнил несколько весьма бестолковых метаний от одной методологии к другой и проголосовал.

      Вроде бы все.

    6. Александр Орлов February 16th, 2009 at 17:58

      Спасибо за детали, ситуация немного прояснилась. Очень напоминает R&D, к которому методологии применять тоже э-э-э интересно. :) Еще раз спасибо, интересная ситуация.

      Я, честно говоря, думал, столько голосов из одной компании. :) Ан нет.

    7. Anton Kukoba February 17th, 2009 at 14:34

      Любая методология – это просто набор эмпирически найденых методов, которые более менее работают при определенных условиях. И ничего более.
      То есть люди работали работали, пытались как-то выкрутиться. Потом осознали что они неплохо выкручиваются. Дальше они проанализировали за счет чего, как им кажется, они достигаю успеха. И начали это продавать: писать книжки, читать лекции, вести тренинги.
      “через ж0пу” – это тоже методология. Просто ее почему-то за методологию не считают из-за того что методы не прописаны четко. И никто не открыл какой-нить консорциум “Effective Zopa Development”.

      Пример относительно нашей фирмы: мы смотрели какие бывают методологии, брали из них то что может прижиться у нас. И поитогу сами пришли к чему-то среднему между XP, DSDM и MSF. Но какой-то конкретной методологии мы четко не следуем.
      Можно сказать что через ж0пy :)

    8. Александр Орлов February 17th, 2009 at 14:42

      Я бы сказал, что это “Другое”. “Через жОпу” показывает отношение людей к тому, что у них происходит. Либо это бардак, либо насаждение методологии сверху, так что получается в итоге через вот это место.

      А когда люди сами для себя что-то выработали, что работает и всех устраивает – это “Другое”.

    9. Danila Kovalev February 17th, 2009 at 22:04

      Да, кстати, я бы вынес waterfall в отдельный топик поскольку это не совсем всё-таки CMM/CMMI. Ну или хотя бы пояснил, что именно это имелось ввиду.

    10. Александр Орлов February 17th, 2009 at 22:47

      Если по-серьезному устраивать, то надо было бы, конечно. Изначально оно шутейное было. Это результаты все перевернули. :)

    11. Sergey Nazarenko February 20th, 2009 at 11:26

      По формату вебинара, что-то определилось? Будет он или не будет?

    12. Александр Орлов February 20th, 2009 at 11:34

      Вебинара не будет. Будет аудио-запись. Обновил пост.

      Так что вопросы лучше задавать здесь или засылать на info@happy-pm.com заранее.

    13. Альберт February 24th, 2009 at 11:31

      Если не поздно добавить вопросик, то мой звучит так: Как перейти от водопадной модели к итерационной?
      Загвоздка в том, что компания крупная, проектов много, еле хватает железа для QA environment/dev environment/integration environment. А придётся для каждой итерации отдельную среду создавать, пусть и небольшую. Есть опыт создания афигенного количества сред?
      Думаю, что переход от “через Ж” к итерационному тоже может уложиться в этот вопрос. Тут ведь не только в методологии загвоздка, но и в наличии железа. А у некоторых даже рабочие станции слабые, судя по постам.

    14. Александр Орлов February 24th, 2009 at 12:46

      Вопрос принят. Еще не поздно. Мероприятие перенесено на вечер 25-го февраля.

    Leave a reply

    You must be logged in to post a comment.