Комментарии 11
В моей практике одним из самых главных рисков и проблем всегда были нечеткие или неадекватные требования заказчика. Причем их не всегда удается распознать сразу. И дальше вся эта нечеткость прорастает в проект до последней строчки кода. И код начинает работать нечетко. Вроде бы так как требовали, но все как-то кривовато. Заказчик недоволен. Потому что сам толком не представлял чего хотел.
Да, безусловно из заказчика нужно вынуть его идею до последней детали, но часто заказчик становится в позицию «У меня нет времени. Вы же профессионалы! Хочу чтобы было пи… ато!». И по-хорошему надо отказываться от такого проекта, но как правило все берутся.
Да, безусловно из заказчика нужно вынуть его идею до последней детали, но часто заказчик становится в позицию «У меня нет времени. Вы же профессионалы! Хочу чтобы было пи… ато!». И по-хорошему надо отказываться от такого проекта, но как правило все берутся.
Мне кажется, тут речь немного о другом. Идея «хочешь что-то переделать — изложи концепцию письменно» мне нравится. Я сейчас сам в позиции новичка, который врубается в проект, и конечно руки чешутся переписать все «правильно», а учитывая, что до этого я полтора года оттимлидил на сложном проекте и привык к тому, что мои технические решения принимаются, держать себя в руках сложновато.
Идея «хочешь что-то переделать — изложи концепцию письменно» мне нравитсяЭто просто шикарная идея. Я в свою бытность РП обычно просто давал разработчику какое-то время запрототипировать свою идею. Но если это архитектурная идея — то её действительно лучше сначала задокументировать и обсудить с коллегами.
Заказчик не любит думать об информационной системе которую ему надо, у него всяких других дел как правило выше крыши. Вот представь что нужно одновременно контролировать поставки, контракты, сроки заключения договоров, обязательства… а тут приходишь ты и начинаешь спрашивать какие-то вопросы о которых надо подумать… Ну нафиг! «у меня нет времени об этом думать» будет самый простой выход и ситуации.
Я в таких случаях, прорабатываю 2 наиболее вероятных варианта понимания требований заказчика и задаю вопрос в виде: А правильно ли я понял что нужно «решение А» или вы имели ввиду «решение Б»? Тут сильно думать уже не так требуется, нужно выбрать один из двух вариантов, если они подходят, или Заказчику придется сделать поправку «Нет, я не это имел в виду....» и тогда он уточнит что же он имел ввиду. и после проработки и анализа новых данных повторяем. Но следует учесть, что если заказчик изначально отказывается то и в подходе с согласованием из вариантов нужно на него не сильно давить, и возможно пакетировать все вопросы требующие решений в 2-3 встречи.
Хороший вопрос содержит 90% ответа (с) народная мудрость.
Я в таких случаях, прорабатываю 2 наиболее вероятных варианта понимания требований заказчика и задаю вопрос в виде: А правильно ли я понял что нужно «решение А» или вы имели ввиду «решение Б»? Тут сильно думать уже не так требуется, нужно выбрать один из двух вариантов, если они подходят, или Заказчику придется сделать поправку «Нет, я не это имел в виду....» и тогда он уточнит что же он имел ввиду. и после проработки и анализа новых данных повторяем. Но следует учесть, что если заказчик изначально отказывается то и в подходе с согласованием из вариантов нужно на него не сильно давить, и возможно пакетировать все вопросы требующие решений в 2-3 встречи.
Хороший вопрос содержит 90% ответа (с) народная мудрость.
Я регулярно сталкивался с ситуацией, когда Заказчик неделями не отвечает на письма, на звонки обещает перезвонить через полчаса, и также пропадает, пока сам его снова не поймаешь. Причем это был внутренний заказчик.
А это точно Заказчик который платит деньги? Или это человек который назначен быть «заказчиком»?
Назначен. В этом-то все и дело. И его руководитель придерживался примерно такой же позиции.
Тогда дело скорее всего кроется в том, что он НЕ ХОЧЕТ брать ответственность на себя. Возможно здесь имеет смысл выяснить почему он не хочет брать ответственность на себя и что с этим можно сделать проработав дерево текущей реальности (еще один инструмент ТОС). Очень интересно с помощью инструментов ТОС моделировать переговоры.
Или ты уже это пробовал?
Или ты уже это пробовал?
Это было давно, в прошлой жизни :) С тех пор я завязал с наемной работой.
Дело было скорее не в нежелании ответственности, а чел реально не умел организовать свое время. Его считали одним из самых перспективных сотрудников компании — молодой, энергичный, очень много всего делает, везде готов съездить, выступить, поговорить, убедить. Оборотная сторона — человек жил в полном цейтноте. Дошло до смешного — не смог попасть на организованный в компании двухдневный тренинг по тайм-менеджементу, т.к. улетел в незапланированную коммандировку.
Не могу сказать что все провалы были из-за этого, и моих косяков как РП хвтатало. Но мне было очень тяжело с ним работать. И это была одна из причин моего ухода.
Дело было скорее не в нежелании ответственности, а чел реально не умел организовать свое время. Его считали одним из самых перспективных сотрудников компании — молодой, энергичный, очень много всего делает, везде готов съездить, выступить, поговорить, убедить. Оборотная сторона — человек жил в полном цейтноте. Дошло до смешного — не смог попасть на организованный в компании двухдневный тренинг по тайм-менеджементу, т.к. улетел в незапланированную коммандировку.
Не могу сказать что все провалы были из-за этого, и моих косяков как РП хвтатало. Но мне было очень тяжело с ним работать. И это была одна из причин моего ухода.
хорошо, когда ты владелец проекта и ставишь задачи (или фильтруешь хотелки клиентов).
когда ты в ит-отделе не ИТ-компании, то бизнес просто диктует хотелки, не анализируя архитектуру и как это ляжет и какие трудности, костыли и сложности это вызовет. т.е. становится вопрос «а можно ли убедить бизнес отказаться от свистелки»
когда ты в ит-отделе не ИТ-компании, то бизнес просто диктует хотелки, не анализируя архитектуру и как это ляжет и какие трудности, костыли и сложности это вызовет. т.е. становится вопрос «а можно ли убедить бизнес отказаться от свистелки»
Если возникает конфликт между желанием заказчика добавить фичу и сложностью ее внедрения или не пониманием целесообразности, то тут также может помочь проработка дерева будущей реальности. С выяснением ответов на вопрос «К чему приведет внедрение этой фичи?» и «Какие реальные потребности клиента/пользователя решит новая фича?».
Результатом проработки этих сценариев и последствий будет или согласие по необходимости внедрения или иное, альтернативное решение. Вполне возможно, что то нужно клиенту это не совсем то что он просит сделать в системе.
Результатом проработки этих сценариев и последствий будет или согласие по необходимости внедрения или иное, альтернативное решение. Вполне возможно, что то нужно клиенту это не совсем то что он просит сделать в системе.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проектная кухня. Снижение архитектурных рисков проекта