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

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

В общем, есть ли способ отодвинуться на это? Если не для этого выпуска, что относительно в будущем? Проблема, которая у меня есть, заключается в том, что я вижу только один способ сделать это, делая все возможное, но выпустить программное обеспечение «как есть», так сказать.

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

отредактируйте: для записи, я не делаю 80-часовые недели сейчас, просто это приходит на ум, как то, что потребуется для покрытия ожидаемого набора функций к дате выпуска.

Хватит делать 80 часовые недели. Это положительное подкрепление . Поскольку они получают продукт вовремя с ожидаемыми затратами, они будут продолжать делать это, независимо от того, что он делает с вами.

Если они не могут правильно планировать время, то это вина руководства. Не твое.

Пусть они пропустят несколько сроков.

В общем, есть ли способ отодвинуться на это? Если не для этого выпуска, что относительно в будущем?

Конечно, есть: пусть они терпят неудачу при таком подходе. Ничто так не учит, как провал.

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

И вам лучше начать делать это с текущим проектом.

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

В качестве запоздалой мысли я думаю, что этот вопрос на самом деле заслуживает ссылки на известную историю EA, описанную в одной из книг Джоэла: EA: The Human Story .

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

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

Искушение состоит в том, чтобы сказать: «Это всегда так и всегда так будет». Но в одном месте, где я работал, было, по крайней мере, ПРЕДЛАГАЕМОЕ решение, если не реализовано ... Один менеджер, наконец, поднял руки и сказал: "Если сверхурочное время программистов используется для закрытия продажи, тогда они должны получить часть комиссия. " Он не был реализован, но он бы выровнял все стимулы более тесно ... программисты были бы рады услышать о новой функции, которая должна была появиться в кратчайшие сроки, потому что они ожидали комиссию, и продавцы будут МЕНЬШЕ склонны создавать такие обстоятельства, потому что они с меньшей вероятностью будут работать в своих интересах.

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

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

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

Клиенты хотят, чтобы это было быстро, и многим будет трудно играть. Это побуждает продажи выполнять взятые на себя обязательства вовремя, чтобы получить что-то подписанное. Подписанный контракт - золото, потому что вы можете приобрести капитал или кредит, используя его. Иногда лучше иметь сжатые сроки, чем вообще ничего не делать.

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

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

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

Я работал по обе стороны дома. Помните, что без продавцов не было бы рабочих мест или проектов.

Как бороться с чрезмерным обязательством продаж : оцените, затем возьмите не менее 130% (всегда планируйте как минимум 30% непредвиденных расходов). Предоставьте и задокументируйте указанную оценку. Поймите, что ваши оценки усилий будут снижены в процессе продаж. Это нормально, просто сделайте так, чтобы руководство вырезало из соглашения о лицензии / продаже / комиссии любое сокращение этих часов. Если вы публичная компания это становится сложнее с VSOE , но пока вы не попали человек , продаж с контрактной ответственностью авансом во время их процесса продаж, она станет вашей отчетностью позже.

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

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

2. Платите продавцам на основе прибыли, а не валовых продаж. Каждый час работы, который они не включают в свои оценки, отрицательно сказывается на их комиссионных.

3. Ограничьте количество часов, которое разработчики могут работать до 40 (или любой другой стандартной рабочей недели в вашей части мира).

4. Заставьте продавцов работать каждый час, когда работают разработчики. Если они хотят, чтобы вы работали сверхурочно, чтобы завершить их проект, они тоже должны быть там. Найдите что-нибудь полезное для них, например, написание документации или создание каллиграфических, освещенных вручную копий шаблонов проектирования и стандартной библиотеки шаблонов C ++ .

5. Попросите разработчиков оценить каждую работу, а не позволять продавцам делать это. По крайней мере, таким образом вы получаете возможность сделать график более разумным. Это не очень хорошее решение, хотя ... разработчики часто ужасно оценивают требуемую работу. Даже если оценка является разумной, непредвиденные события могут помешать вам достичь своей цели. Кроме того, мы все склонны не работать в начале длинного проекта с той же срочностью, что и мы, когда приближается крайний срок. Это факторы, которые мотивируют короткие циклы разработки, которые поддерживают сторонники Agile.

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

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

Уволиться

В ответах уже есть много разумных предложений, которые, как мы надеемся, могут помочь решить эти дисфункциональные отношения. Но в конце концов, вы решаете, сколько вы хотите работать.

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

Вот что вы можете сделать:

• Скажите своему боссу: «Мне пришлось работать намного больше сверхурочно, чем я хочу. С этого момента я не буду работать больше X часов в месяц».
• Как и предполагали другие, оцените, сколько часов уйдет вперед. Напомните им, что «при моем ограничении X часов в месяц я, вероятно, не закончу это к крайнему сроку». Поместите это в электронное письмо для дальнейшего использования.
• Обратитесь к этому электронному письму, когда крайний срок пройдет мимо. «Видите? Как и предполагалось, мы не смогли бы уложиться в этот срок в разумные рабочие часы».
• Если они по-прежнему заставляют вас работать сверхурочно, и все усилия по общению терпят неудачу, выходите.

Личный опыт

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

Я также ясно выразил это желание в моем интервью для моей новой работы, и получил восторженный ответ. Они сдержали свое слово: меня редко просят работать здесь сверхурочно.

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

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

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

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

Вы ничего не можете сделать, чтобы изменения произошли на самом деле, но вы обязательно должны сообщить об этом своему менеджеру.

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

Изменить, чтобы добавить: не позволяйте им говорить вашу оценку вниз. Будьте уверены, что это правильно, и придерживайтесь этого. Они будут пытаться торговаться с вами, но не позволяйте им.

Одно предложение, которое еще не пришло: ретроспективы .

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

Но очень четко говорите своему руководству, что каждый раз, когда вам нужно делать больше 40 часов в неделю, чтобы выполнить работу, все участники проекта должны сидеть в комнате после доставки продукта , выяснять, что пошло не так, и что мы можем сделать, чтобы это не случилось снова. Или, что еще лучше, у каждого проекта должна быть ретроспектива для обсуждения того, что прошло хорошо, а что - нет.

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

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

Нет абсолютно никакого способа бороться с этим полностью. Сама природа продаж чрезмерна. Как торговый представитель, вы должны сделать так, чтобы проблемы потенциального клиента волшебным образом исчезли. Хорошие торговые представители будут только немного преувеличивать, плохие будут вызывать большое смущение.

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

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

Трудно ответить, не зная структуру вашей компании.

Вот некоторые общие инструменты, которые могут помочь:

• Согласовать (но ответственных, а не продаж) контроль качества
• Иметь дорожную карту продукта (внутреннюю и внешнюю)

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

Имея дорожную карту продукта , Sales знает, что они могут и не могут обещать клиентам. Если они хотят изменить дорожную карту, они должны обсудить ее с менеджером по продукту / менеджером проекта / менеджером по развитию или кем-либо еще, кто ее меняет.

Если они обещают клиенту что-то, о чем еще не договорились, не повезло. Надеемся, что ваша дорожная карта основана на рыночных данных о потребностях клиентов. «Что именно вы предлагаете нам исключить из этих восьми других высокоприоритетных функций, которые у нас есть доказательства потребностей наших клиентов?»

Последнее, как уже ожидалось, не работает 80 часовых недель. Вы даже не помогаете компании, потому что вы просто помогаете им вырыть более глубокую яму.

нет

Я попытался сделать это двухбуквенным ответом, и стек не позволил бы мне ... но ответ

нет

Что, конечно, не совсем верно, если вы владеете / управляете компанией. Если вы находитесь в таком положении, вы можете затащить отдел продаж за уши и «поговорить». Если, однако, и, как я подозреваю, вы просто «скромный» технический человек, вы можете подать жалобу «ВВЕРХ» в цепи командования. При этом, по моему опыту, в компаниях, где это происходит, руководство знает о ситуации и не заботится о ней.

Покажите им это изображение (или это ) и скажите им, что вы работаете с невозможным треугольником.

  ·-----------------------·
 / \                       \
·   \   ·-------------------·
 \   \   \                 /
  \   \   \-----------·   /
   \   \   \     /   /   /
    \   \   \   /   /   /
     \   \   \ /   /   /
      \   \   /   /   /
       \   \ /   /   /
        \   ·   /   /
         \     /   /
          \   /   /
           \ /   /
            ·---·

В любом проекте, если вы исправите два угла из этих трех:

• Время
• Объем
• Качество

... тогда третий - единственный гибкий. Что делает невозможным, так это ожидания. Если они всегда устанавливают слишком короткое время и слишком большой объем, то качество всегда будет страдать. В гибком проекте все три угла более или менее гибки.

(Отказ от ответственности: я исключаю фактор стоимости из традиционного проектного треугольника и делаю качество углом. Время - это стоимость в программных проектах.)

Я надеюсь, что вам удастся проложить путь к более гибкому управлению проектами.

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

Поскольку продавцы понимают деньги больше, чем что-либо еще, поговорите с ним в таких терминах.

С Agile-разработкой мы видим, что консультанты продают очки по ~ 1000-1500 каждый. Если вы можете изменить процесс продаж на то, где они должны продавать, по шкале баллов, то отдел продаж будет вынужден работать с командой разработчиков, чтобы прийти к разумным оценкам.

Все сводится к одной критической точке; Если вы не думаете, что сможете поддерживать темп, необходимый для выполнения графика продаж, обещанного, тогда не принимайте участие в работе. Если продажи завышены, это не ваша проблема, пока вы не согласитесь на работу. ТОГДА это твоя проблема. Напомните своему боссу, что все продавцы должны сказать «да», и они получат чек; Вы на самом деле выполняете обещания, поэтому, если вы скажете, что это не сработает, ваш босс должен прислушиваться. Если вам не повезло иметь менеджера, который слушает его отдел продаж больше, чем его персонал по разработке того, что является и не возможно, тогда у вас есть PHB Дилберта, и вы должны обновить свое резюме.

Это одна из причин, по которой мне нравится Agile; команда разработчиков вовлечена в процесс от начальных обсуждений проекта. Вы можете откалибровать «точку» с обоих концов; Команда разработчиков решает (явно или эмпирически) примерно, сколько человеко-часов разработки присуще точке, которую затем руководство может использовать для расчета баллов в неделю, баллов в месяц и т. д., что приводит к показателю в долларах. На этом этапе ваша группа продаж теперь имеет данные, относящиеся к стоимости и времени, которые требуются для текущего уровня персонала, чтобы получить текущий объем работ. Если они получат слишком много, как только у них появятся эти цифры, они окажутся на заднице.

Определите работу после того, как они дадут ее вам, и дайте им знать, сколько времени это займет. Тогда, когда они кричат ​​об этом, скажи им.

«Мне жаль, что вы взяли на себя это обязательство, но, учитывая имеющиеся в моем распоряжении ресурсы, это займет X часов»

Делай это каждый раз ... это работало на меня.

По сути, скажите им, что они могут быть быстрыми, дешевыми и хорошими, выберите два.

Там на самом деле есть путь - реальный путь, а не пустая банальность - но вам это может не понравиться.

Попросите кого-нибудь из команды разработчиков участвовать в процессе продаж .

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

Это действительно работа для бизнес-аналитика или менеджера проекта. Есть причина, по которой эти рабочие места так хорошо оплачиваются во многих компаниях; они объединяют два очень важных и отличных набора навыков. Если у вас нет настоящего BA или PM, но у вас есть старший разработчик или архитектор с социальными навыками, они тоже могут это сделать.

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

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

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

Возможно, вы не являетесь их менеджерами, но если вы документируете все это в письменном виде еще до того, как они начнут вести переговоры, тогда вы будете на более прочной основе с высшим руководством, когда люди начнут задавать вопросы о том, почему проект отстает от графика. Но речь идет не только о CYA; Отдел продаж, честно говоря, не имеет ни малейшего представления о том, сколько времени займет выполнение определенных задач, и вы делаете им одолжение, предоставляя им исчерпывающую информацию.

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

И если вы действительно, честно говоря, не можете продать менеджмент по этой идее, то могу ли я предложить найти нового работодателя? Потому что ваш может быть не так много в любом случае.

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

Вы когда-нибудь пробовали продавать программное обеспечение? Многим разработчикам может показаться, что это не лучший ответ, но пока вы не попробуете, будет сложно увидеть бизнес со стороны продаж. Если вы отличный разработчик, напишите что-то, что вы действительно хотите написать, и продайте это. Вы можете видеть, что у них есть действительные баллы, или вы можете видеть, что у них их нет!