Комментарии 81
Только вчера наблюдал все стадии ) У меня еще прекрасный кейс с отпиливанием власти в ИТ продажником, который разворачивается прямо на моих глазах. Напишу в личку.
Очень интересно узнать, что у вас, так у меня тоже есть свой кейс по опиливанию власти в ИТ продажником, это же чистая квинтэссенция всех означенных проблем.
Тоже сейчас наблюдаю отпиливание власти продажником. Власти в компании. Число желающих «перевернуть рынок» и «перспективных людей» без знаний предметной области, но очень-очень мотивированных уже начинает превышать число работающих работу. Только и разговоров какие мы тут все крутые и какие чудеса творим, при том что в реальности это далеко не так. Разработчики уже утекать начали и такими темпами компания начнёт торговать сферической крутизной в вакууме. Надеюсь я ошибаюсь и просто что-то не понял.
А напишите в личку по вашему кейсу. В целом когда продажи хотят захватить власть — это интересно. Как это происходит и чем заканчивается -)
Большой технический долг через год-два, отсутствие какой-либо документации, комментарии в коде только в стиле «Другая фигня, которая крутит <далее на слэнге, который уже мало кто понимает>», имеющиеся поэтому программисты мало что понимают в том, что происходит и вместе с бизнесом разводят руками и глазами, постоянные падения, так как инфраструктура не готова к появившимся нагрузкам, а те, кто всё это писал уже давно уволены или ушли сами из-за такого отношения.
У нас власть уже захватил продажник со спутанным мышлением, сочувствую и желаю думать о смене работы =)
Самый главный вывод: «нужно постараться» — это приглашение придушить продажника. Пошел внедрять!
Как неправильно: “Мы считали, что затраты будут 1М, но придется сделать все за 0,4М и еще клиент хочет дополнительный функционал!”
Как правильно: “Уважаемые разработчики, что реально сделать за 0,4М?”
вопрос1 — если продается штучный продукт, то оценка функционала должна предварительно согласовываться с разработчиком, иначе на каком основании продажником получена цифра 1М (3М или 10тыс)?
вопрос2 — если продается коробочный продукт, для которого есть фикс-прайс на единици функционала, то зачем ему переспрашивать у разработчиков?
Ответил ниже: https://habrahabr.ru/post/318350/#comment_9987376
Продажник: Сколько будет сделать это?
Разработчик: 1М.
Продажник клиенту: 1М.
Клиент: у нас бюджет 0.4М. И мы ещё хотим хотелок.
Продажник: ок, сделаем.
Скорее всего будет как-то вот так:
Продажник разработчику: Сколько будет сделать это?
Разработчик: 1М, т.к. А, Б, В и Г по 0.2М + ещё 0,2М на тестирование всего вместе и ПМ-затраты.
Продажник клиенту: вы же понимаете, что всё это будет стоит в районе 3М?
Клиент: у нас бюджет 0.4М. И мы ещё хотим хотелок.
Продажник: мы с вами крутые парни/давно вместе работаем/у вас голубые глаза, а голубой наш корп.цвет/etc, так что за 0.4М мы можем сделать какие-то отдельные вещи плюс ещё немного на ПМ и качественное тестирование, вот примерный прайс: А, Б, В и Г по 0.4М
Клиент: тогда мы объявим тендер
Продажник: мы готовы сделать вам огромную скидку, чтобы получить себе в карму от вас +100500 и предлагаем сделать А и Б за те же 0,6М (оценку на фитчи В, Г согласуем чуть позже), что и наши прямые конкуренты, только срок будет чуть больше, чем у них, т.к. у нас больше опыта в этой области и мы будем делать качественное тестирование и демонстрировать работу в течении её выполнения, чтобы к дедлайну у вас уже был готовый продукт.
Клиент: по рукам
Продажник разработчику: Сколько будет сделать это?
Разработчик: 1М, т.к. А, Б, В и Г по 0.2М + ещё 0,2М на тестирование всего вместе и ПМ-затраты.
Продажник клиенту: вы же понимаете, что всё это будет стоит в районе 3М?
Клиент: у нас бюджет 0.4М. И мы ещё хотим хотелок.
Продажник: мы с вами крутые парни/давно вместе работаем/у вас голубые глаза, а голубой наш корп.цвет/etc, так что за 0.4М мы можем сделать какие-то отдельные вещи плюс ещё немного на ПМ и качественное тестирование, вот примерный прайс: А, Б, В и Г по 0.4М
Клиент: тогда мы объявим тендер
Продажник: мы готовы сделать вам огромную скидку, чтобы получить себе в карму от вас +100500 и предлагаем сделать А и Б за те же 0,6М (оценку на фитчи В, Г согласуем чуть позже), что и наши прямые конкуренты, только срок будет чуть больше, чем у них, т.к. у нас больше опыта в этой области и мы будем делать качественное тестирование и демонстрировать работу в течении её выполнения, чтобы к дедлайну у вас уже был готовый продукт.
Клиент: по рукам
речь конечно о варианте 1
— т.е. оценили у команды проект, а потом клиент говорит: «нам все нравится, но бюджет такой», но продажник не может сказать, что «ничего не получится, прощайте», он должен «найти варианты!!!»
Ну и понеслась игра с договоренностями.
Как вариант: «нам все нравится, но нужно быстрее»
Это удивительно, но с коробочным продуктом такое тоже часто бывает: «нам все нравится, покупаем, добавьте такой функционал, ведь это очевидный баг что его нет».
Продажник не может сказать: «Либо берете, либо нет». Он бежит к команде с вопросом: «Поправьте баг!!!!», а он не баг, а новый функционал, и понеслась -)))
— т.е. оценили у команды проект, а потом клиент говорит: «нам все нравится, но бюджет такой», но продажник не может сказать, что «ничего не получится, прощайте», он должен «найти варианты!!!»
Ну и понеслась игра с договоренностями.
Как вариант: «нам все нравится, но нужно быстрее»
Это удивительно, но с коробочным продуктом такое тоже часто бывает: «нам все нравится, покупаем, добавьте такой функционал, ведь это очевидный баг что его нет».
Продажник не может сказать: «Либо берете, либо нет». Он бежит к команде с вопросом: «Поправьте баг!!!!», а он не баг, а новый функционал, и понеслась -)))
Имхо статья написана задолбаным разработчиком с огромным чсв и звездностью. Многие срочные форсмажоры могут решаться как "сколько нам надо экстра денег для "такой то задачи" если что то пошло не так. Деньги — это либо премия разработчику, либо найм дополнительных, если никак. Но извините ходить и целовать в Ж какого то сабжа с зашкаленным чсв, рискуя угробить проект это слабость руководителя. Сам имею опыт с обеих сторон не менее 5 лет. Свое мнение никому не навязываю, у каждого свой опыт. И я считаю что разработчика с зашкаленным чсв лучше выгнать сразу, тк паршивая овца все стадо портит, но мы тут опять поднимаем тему с "звездными программистами" именно они бычно ковыряются на тему "не так сказали, не то спросили". Кто хочет работать и любит свою работу будет работать, а кто ищет предлоги не работать — всегда их найдет. Или руководитель окажется идиод, или заказчик но точно не он сам, ведь он такой душечка знает 48 языков программирования но пишет почему то только на бэйсике гэвэ.
Не могли бы Вы более полно раскрыть свою мысль, почему оргомное чсв и звездность?
Ну, скажем так, в статье все поголовно продажники плохи, разработчики наши все хороши (кроме бангладешцев), и непогрешимы.
Никакого анализа нет, попытки понять ту сторону нет. Только требования, я бы даже сказал, топанье ножкой.
Я ничего не пропустил?
Никакого анализа нет, попытки понять ту сторону нет. Только требования, я бы даже сказал, топанье ножкой.
Я ничего не пропустил?
Смысл статьи сформулирован однобоко, разработчик выставляется высшим разумом а продажник — недалеким недоспециалистом. Вопроса о том, что же будет делать разработчик без продажника не поставлено. Мысли о том, что разработчик врядли сможет продать свой труд эффективнее специалиста продажника, я не увидел, автор явно не видит выгоды в таком союзе. Поэтому я и пришел к выводу что автор по всей видимости считает себя эдакой звездой которой все должны кланяться, а те кто ему же добывает деньги по его мнению только мешают и не правильно все понимают. Типичный шаблон наемного работника, который работает только за деньги, не любит свою работу и не уважает своих партнеров, осложненный мировосприятием через призму своей "крутости как специалиста". Такие разработчики почему то не понимают, что их можно заменить, не понимают что сам по себе их код никому не нужен, пока тот же ненавистный продажник не придумает как и кому продать, и пока маркетолог не завернет все в красивую обертку. Конечно часть этих функций часто бывают за заказчиком, но от этого смысл не меняется, разработчик может сделать то, что знает как продать заказчик. Если разработчик такой умный и ему все мешают, почему же он сам не может выполнить все функции продажника, если знает лучше чем сам продажник как надо делать и как с ним звездой надо общаться.
Дополню еще. Из статьи не ясно, кто понимается под "продажником". Непонятно почему разработчик напрямую с ним взаимодействует. Все поставленные вопросы находятся в зоне ответственности руководителя проекта а не продажника. Класический sales это явно не тот кто ставит задачи программистам, иначе это какой то идиотизм. Из текста понятно что проектом руководит почему то неспециалист, непонятна роль тимлида, прожект менеджера.
Хорошо, что вам удается все организовать так со всех сторон, что все счастливы.
Я пишу тут кейсы про несчастье:
1. Продажник работает напрямую с разрабами, такое бывает.
2. Сами разрабы что-то продали, такое бывает
3. Сэйлзы насилуют проджекта, такое бывает
4. Идиотизм наш друг, такое бывает.
5. Сэйлзы лезут через голову тимлида и проджекта, такое бывает
6. В союзе с продажником лично я (автор) вижу огромную выгоду, но не все ее видят, и на самом деле бывают ситуации когда выгоднее без продажников. Тот же upwork. Так что в РФ разработчик еще как может продать свой труд эффективнее без продажника, нельзя это отрицать.
7. Я не наемный работник, у меня свое дело. Я не разработчик, а аналитик. Так что все это скорее обобщение типичных ситуаций, которые я наблюдаю постоянно на практике.
8. Партнеров уважаю, крутым себя не считаю, я ведь аналитик -)
9. Про заменимость понимаю, ее действительно часто недооценивают.
10. Продажников люблю! Честно! Обожаю продажников, без них не умею зарабатывать -(
11. Статья и правда однобокой получилась, осознанно. Мне казалось это плюсом на момент написания. Теперь я слышу критику, что однобокость не нравится.
12. Знаю многих разработчиков, которые отличные продажники.
13. Классическая схема разработчик-маркетолог-продажник-клиент — подходит не для всех проектов и не для всех продуктов. И часто это добавляет боли, когда роли смешиваются.
14. Под продажником понимаю роль, которая договаривается с клиентом о чем-то.
Я пишу тут кейсы про несчастье:
1. Продажник работает напрямую с разрабами, такое бывает.
2. Сами разрабы что-то продали, такое бывает
3. Сэйлзы насилуют проджекта, такое бывает
4. Идиотизм наш друг, такое бывает.
5. Сэйлзы лезут через голову тимлида и проджекта, такое бывает
6. В союзе с продажником лично я (автор) вижу огромную выгоду, но не все ее видят, и на самом деле бывают ситуации когда выгоднее без продажников. Тот же upwork. Так что в РФ разработчик еще как может продать свой труд эффективнее без продажника, нельзя это отрицать.
7. Я не наемный работник, у меня свое дело. Я не разработчик, а аналитик. Так что все это скорее обобщение типичных ситуаций, которые я наблюдаю постоянно на практике.
8. Партнеров уважаю, крутым себя не считаю, я ведь аналитик -)
9. Про заменимость понимаю, ее действительно часто недооценивают.
10. Продажников люблю! Честно! Обожаю продажников, без них не умею зарабатывать -(
11. Статья и правда однобокой получилась, осознанно. Мне казалось это плюсом на момент написания. Теперь я слышу критику, что однобокость не нравится.
12. Знаю многих разработчиков, которые отличные продажники.
13. Классическая схема разработчик-маркетолог-продажник-клиент — подходит не для всех проектов и не для всех продуктов. И часто это добавляет боли, когда роли смешиваются.
14. Под продажником понимаю роль, которая договаривается с клиентом о чем-то.
Злой комментарий, на надменный пост.
Впрочем, с постом не согласен больше, если автор остальных считает идиотами по признаку профессии, то тут явно есть какое-то недоразумение.
А тот факт, что нет сильного представителя со стороны разработчика, кто смог бы настроить взаимодействие с продажами говорит, мне лично, что ситуация устраивает. Ну то есть, мы их, продажников не любим, но как с нами разговаривать, мы не скажем и будем издеваться.
Хотя нет, вот пост написан, но все равно с издевкой, и надменно.
В разработке мы все пришли к тому чтобы UI был прекрасен, и стали на него обращать много внимания. Может быть нужно чтобы наш межличностный интерфейс тоже стал дружелюбнее?
Впрочем, с постом не согласен больше, если автор остальных считает идиотами по признаку профессии, то тут явно есть какое-то недоразумение.
А тот факт, что нет сильного представителя со стороны разработчика, кто смог бы настроить взаимодействие с продажами говорит, мне лично, что ситуация устраивает. Ну то есть, мы их, продажников не любим, но как с нами разговаривать, мы не скажем и будем издеваться.
Хотя нет, вот пост написан, но все равно с издевкой, и надменно.
В разработке мы все пришли к тому чтобы UI был прекрасен, и стали на него обращать много внимания. Может быть нужно чтобы наш межличностный интерфейс тоже стал дружелюбнее?
Очень странно, когда про общие рекомендации по работе над ошибками говорят: "А что это Вы только про ошибки? Зазнаётесь!" Это же не священное писание с универсальной формулой бытия, это именно и конкретно пожелания продаванам, как сделать хорошо разрабам. И если разрабы, в свою очередь, стараются сделать хорошо продаванам (но это за рамками темы статьи) то они смогут договориться ко всеобщему удовлетворению
Зашкаленное ЧСВ — это желание иметь постановку задачи? «Постарайтесь» — это не аргумент и не постановка задачи нормальный работник всегда старается, эффективность его труда мало зависит от важности для бизнеса стоящей задачи.
Как правильно: “Уважаемые разработчики, что реально сделать за 0,4М?”
Ответ будет: купить мне авто и не е}%*ть мозги.
Ответ будет: купить мне авто и не е}%*ть мозги.
Всегда немного пугала такая постановка вопроса, типа «Как вы должны обращаться со своими проблемами к разработчику?».
Мне, как и любому человек в IT, понятно раздражение и негодование по поводу условных «менеджеров» и «продажников», которые наобещали что-то не посоветовавшись, скроили спринт исходя из положения Венеры относительно Меркурия, а не исходя из эстимейтов.
Но это не значит, что разработчик должен восседать на золотом троне из черепов и, отвлекаясь изредка от IDE, снисходить до объяснения другим сотрудникам компании их ничтожности.
Вы, блин, делаете один продукт. Ваш код никому не нужен, если он не будет продан. А его усилия по продажам будут тщетны, если вы напишете говно.
В конце концов, задача разработчика — не запушить код с кодом, который скомпилируется, а создать техническое решение представленной проблемы.
И для этого надо слышать, что тебе говорят. Надо слышать, что наши эстимейты слишком дороги для потенциальных клиентов. Надо слышать, что клиентам надо ещё фичи X, Y и Z.
Нужен диалог внутри команды, а не вот это вот «понабежало тут тленных гуманитариев со своими хотелками, мешают хабр читать».
Как нужно говорить с программистами? Да ровно так же, как и с любым сотрудником компании.
Мне, как и любому человек в IT, понятно раздражение и негодование по поводу условных «менеджеров» и «продажников», которые наобещали что-то не посоветовавшись, скроили спринт исходя из положения Венеры относительно Меркурия, а не исходя из эстимейтов.
Но это не значит, что разработчик должен восседать на золотом троне из черепов и, отвлекаясь изредка от IDE, снисходить до объяснения другим сотрудникам компании их ничтожности.
Вы, блин, делаете один продукт. Ваш код никому не нужен, если он не будет продан. А его усилия по продажам будут тщетны, если вы напишете говно.
В конце концов, задача разработчика — не запушить код с кодом, который скомпилируется, а создать техническое решение представленной проблемы.
И для этого надо слышать, что тебе говорят. Надо слышать, что наши эстимейты слишком дороги для потенциальных клиентов. Надо слышать, что клиентам надо ещё фичи X, Y и Z.
Нужен диалог внутри команды, а не вот это вот «понабежало тут тленных гуманитариев со своими хотелками, мешают хабр читать».
Как нужно говорить с программистами? Да ровно так же, как и с любым сотрудником компании.
Согласен, проблема взаимопонимания гораздо шире.
Если бы разработчики могли влезть в шкуру продажников, а продажники в шкуру разработчиков, можно бы было не писать вообще.
Все-таки целью было немного помочь продажникам научиться говорить с разработчиками и с любыми другими сотрудниками тоже.
Помогать всем остальным правильно общаться с продажниками — такой цели не стояло. Может быть зря -)
И да разные сотрудники обладают разными ролями — это одна из причин провалов в коммуникации.
Если бы разработчики могли влезть в шкуру продажников, а продажники в шкуру разработчиков, можно бы было не писать вообще.
Все-таки целью было немного помочь продажникам научиться говорить с разработчиками и с любыми другими сотрудниками тоже.
Помогать всем остальным правильно общаться с продажниками — такой цели не стояло. Может быть зря -)
И да разные сотрудники обладают разными ролями — это одна из причин провалов в коммуникации.
Вам уже откомментили выше, что «помочь продажникам научиться говорить с разработчиками» у вас получилось очень… надменно, однобоко и… озлобленно, что ли.
Проблема в том, что ситуация никак не меняется от того, придут ли к разработчику с фразой «Нам нужно сделать X за 0.5 эстимейта» или с фразой «Что мы можем сделать за 0.5 эстимейта?».
У вас все ещё есть хотелка X (т.е. проблема, которую надо решить) и срок T.
Ответ тоже должен быть один и тот же: «За это время мы сможем сделать вот это и это, если повезет — ещё вот это. А полноценного X не получится точно».
Вы же, вместо того, что бы оценить ситуацию и предложить решение, вне зависимости от формулировки, хотите каких-то заискиваний со стороны коллег, в духе «Дяденька разработчик, ну сделайте, ну пожалуйста».
И это тупиковый подход.
Ещё раз повторюсь. Независимо от ролей, пула задач, размера зарплат и всего остального — вы делаете одно и то же дело. Разработчик и продажник выполняют разные функции, но ожидаемый результат деятельности один — хороший и востребованный продукт.
Если кто-то из участников не понимает этого факта, то уже пофигу, какими формулировками обмениваться. Всё равно ничего не выйдет.
И совсем не нужно «влезать в шкуру продажника» и наоборот. Нужно принять за данность, что продажник со своей стороны приложил все усилия, что бы выбить максимально выгодные для команды условия, а разработчик приложит все усилия, что бы выпускаемый продукт решал поставленную проблему в рамках тех ресурсов, которые удалось выбить(потому что если кто-то херово работает — это уже не проблема коммуникации, а проблема «не работайте с мудаками»).
P.S. Я, если что, не продажник. Я просто за справедливость.
Проблема в том, что ситуация никак не меняется от того, придут ли к разработчику с фразой «Нам нужно сделать X за 0.5 эстимейта» или с фразой «Что мы можем сделать за 0.5 эстимейта?».
У вас все ещё есть хотелка X (т.е. проблема, которую надо решить) и срок T.
Ответ тоже должен быть один и тот же: «За это время мы сможем сделать вот это и это, если повезет — ещё вот это. А полноценного X не получится точно».
Вы же, вместо того, что бы оценить ситуацию и предложить решение, вне зависимости от формулировки, хотите каких-то заискиваний со стороны коллег, в духе «Дяденька разработчик, ну сделайте, ну пожалуйста».
И это тупиковый подход.
Ещё раз повторюсь. Независимо от ролей, пула задач, размера зарплат и всего остального — вы делаете одно и то же дело. Разработчик и продажник выполняют разные функции, но ожидаемый результат деятельности один — хороший и востребованный продукт.
Если кто-то из участников не понимает этого факта, то уже пофигу, какими формулировками обмениваться. Всё равно ничего не выйдет.
И совсем не нужно «влезать в шкуру продажника» и наоборот. Нужно принять за данность, что продажник со своей стороны приложил все усилия, что бы выбить максимально выгодные для команды условия, а разработчик приложит все усилия, что бы выпускаемый продукт решал поставленную проблему в рамках тех ресурсов, которые удалось выбить(потому что если кто-то херово работает — это уже не проблема коммуникации, а проблема «не работайте с мудаками»).
P.S. Я, если что, не продажник. Я просто за справедливость.
Постойте, я тоже за справедливость!!!
1. Ок, статья однобокая, я это признаю и учту на будущее.
2. С чего вы взяли, что «продажник со своей стороны приложил все усилия, что бы выбить максимально выгодные для команды условия» — вы это серьезно?
3. «разработчик приложит все усилия, что бы выпускаемый продукт решал поставленную проблему в рамках тех ресурсов» — в идеальном мире, да. А ведь он может, например, не понять этого из-за «спутанности сознания» например. К чему он приложит усилия тогда?
4. Ведет ли отличное взаимопонимание продаж и разработки к «хорошему востребованному продукту»???
Все ли считают «хороший и востребованный продукт» своей целью? Да все ли вообще знают что надо для этого делать?
Вот я не знаю, как сделать продукт востребованным, честно! И я честно трачу 80% своего рабочего времени на то, чтобы узнать и записать что есть «хороший» и в чем это измеряет клиент.
1. Ок, статья однобокая, я это признаю и учту на будущее.
2. С чего вы взяли, что «продажник со своей стороны приложил все усилия, что бы выбить максимально выгодные для команды условия» — вы это серьезно?
3. «разработчик приложит все усилия, что бы выпускаемый продукт решал поставленную проблему в рамках тех ресурсов» — в идеальном мире, да. А ведь он может, например, не понять этого из-за «спутанности сознания» например. К чему он приложит усилия тогда?
4. Ведет ли отличное взаимопонимание продаж и разработки к «хорошему востребованному продукту»???
Все ли считают «хороший и востребованный продукт» своей целью? Да все ли вообще знают что надо для этого делать?
Вот я не знаю, как сделать продукт востребованным, честно! И я честно трачу 80% своего рабочего времени на то, чтобы узнать и записать что есть «хороший» и в чем это измеряет клиент.
Статья и должна быть однобокая! И в диалоге с другой статьёй стороной и рождается взамопнимание. Совмещать все роли в одной голове — не самая хорошая идея, хотя бы потому, что скиллы объекты приложения основных усилий по-жизни — совершенно разные по свойствам
Пункт 2: Потому что в этом задача продажника. Точнее не так. Это его работа.
Выбить максимум денег при минимуме усилий со стороны компании. Минимум усилий, как вы понимаете, это соотношение количества необходимых действий и количества времени на эти действия.
Если этот пункт не выполняется — продажник не делает свою работу и его надо не учить разговаривать с разработчиками, а увольнять.
Пункт 3: У разработчика есть задача, которую надо сделать (т.е. его работа). Он должен приложить все возможные (естественно в рамках рабочих процессов) усилия, что бы выполнить её в рамках тех ресурсов, которые имеются.
И под «выполнить» я имею ввиду не только написать код. Я имею ввиду «закрыть задачу».
Можно убедить команду (читай компанию), что реализовывать данную задачу не нужно (или нужно не сейчас), или нужно, но в другом виде. Или просто взять и сделать, если реализация кажется правильной и ресурсов на неё хватает.
Пункт 4: Отличное взаимопонимание между участниками команды сильно повышает шансы продукта стать «хорошим» и «востребованным». Не только между продажником и разработчиком. Между участниками команды вообще.
В целом да, если каждый из участников выполняет свою работу добросовестно и внутри команды есть синергия и взаимопонимание -> это ведет к созданию «хорошего» и «востребованного» продукта.
Я, лично, не вижу причин почему может быть иначе.
По поводу «все ли считают» и «все ли понимают» -> лучше не работать с людьми, которые считают иначе. А понимание что делать очень быстро появляется при наличии взаимопонимания и налаженной коммуникации между участниками команды.
Когда я говорю, что все «понимают» — я не имею ввиду, что каждый из участников уверен, что лучше клиента и всех остальных понимает, как надо сделать.
Я говорю, что есть люди, которые работают с потенциальными клиентами и изучают их потребности. Есть люди, которые предлагают решения этих потребностей. Есть люди, которые реализуют эти решения.
Если они все делятся результатами своей работы друг с другом и нормально коммуницируют, то внутри команды есть понимание что такое «хорошо» и «востребовано».
Выбить максимум денег при минимуме усилий со стороны компании. Минимум усилий, как вы понимаете, это соотношение количества необходимых действий и количества времени на эти действия.
Если этот пункт не выполняется — продажник не делает свою работу и его надо не учить разговаривать с разработчиками, а увольнять.
Пункт 3: У разработчика есть задача, которую надо сделать (т.е. его работа). Он должен приложить все возможные (естественно в рамках рабочих процессов) усилия, что бы выполнить её в рамках тех ресурсов, которые имеются.
И под «выполнить» я имею ввиду не только написать код. Я имею ввиду «закрыть задачу».
Можно убедить команду (читай компанию), что реализовывать данную задачу не нужно (или нужно не сейчас), или нужно, но в другом виде. Или просто взять и сделать, если реализация кажется правильной и ресурсов на неё хватает.
Пункт 4: Отличное взаимопонимание между участниками команды сильно повышает шансы продукта стать «хорошим» и «востребованным». Не только между продажником и разработчиком. Между участниками команды вообще.
В целом да, если каждый из участников выполняет свою работу добросовестно и внутри команды есть синергия и взаимопонимание -> это ведет к созданию «хорошего» и «востребованного» продукта.
Я, лично, не вижу причин почему может быть иначе.
По поводу «все ли считают» и «все ли понимают» -> лучше не работать с людьми, которые считают иначе. А понимание что делать очень быстро появляется при наличии взаимопонимания и налаженной коммуникации между участниками команды.
Когда я говорю, что все «понимают» — я не имею ввиду, что каждый из участников уверен, что лучше клиента и всех остальных понимает, как надо сделать.
Я говорю, что есть люди, которые работают с потенциальными клиентами и изучают их потребности. Есть люди, которые предлагают решения этих потребностей. Есть люди, которые реализуют эти решения.
Если они все делятся результатами своей работы друг с другом и нормально коммуницируют, то внутри команды есть понимание что такое «хорошо» и «востребовано».
Есть разница. На первое я скажу «не реально», мне скажут " постарайся", я скажу «хорошо» и мы сорвем сроки, потому что я всегда стараюсь и если менеджер считает по другому, то ему нужно меня увольнять. На второе может начаться конструктивный диалог.
У нас дизайнер достаёт макеты из чёрного цилиндра.
Не могу понять какая сила удерживает разработчиков в столь ужасных условиях труда.
Вроде же просто все — либо смириться с ситуацией, либо найти правильную компанию, где умеют обращаться с разработчиками.
Вроде же просто все — либо смириться с ситуацией, либо найти правильную компанию, где умеют обращаться с разработчиками.
Про то, что разработчик без продажника никому не нужен, уже написали. А я напишу, что при грамотной организации процесса разработки (сфера ответственности менеджеров и тим-лидов) разработчик вообще низводится до уровня заменяемой в 1 день рабочей силы.
Конечно, для этого нужны в первую очередь объёмы заказов, но у любой успешной конторы всё к этому идёт. Если вы сами разговариваете с продажником и им недовольны — ваша контора только на пути к своему успеху (дипломатично выражаясь)
Конечно, для этого нужны в первую очередь объёмы заказов, но у любой успешной конторы всё к этому идёт. Если вы сами разговариваете с продажником и им недовольны — ваша контора только на пути к своему успеху (дипломатично выражаясь)
1. Возможностей жить без продажников все больше. Можно использовать биржи. Создали маленькое успешное приложение: для Android, iOS, WM, FB — жизнь удалась, работаете в свое удовольствие.
2. Хочу ли я быть винтиком в машине? Скорее нет. Хочу ли я, чтобы разработчики были винтиком в машине? Нет. Хочу ли я чтобы продажники были винтиками, тоже нет!
3. Заменимость обычно недооценивают. Но переоценивать ее тоже не нужно.
Ты проживешь без королей? — Солдат сказал: Изволь!
— А ты без гвардии своей?
— Ну нет! — сказал король.
4. Не поверите, но с продажниками у меня полное взаимопонимание обычно, равно как и с разрабами -)
2. Хочу ли я быть винтиком в машине? Скорее нет. Хочу ли я, чтобы разработчики были винтиком в машине? Нет. Хочу ли я чтобы продажники были винтиками, тоже нет!
3. Заменимость обычно недооценивают. Но переоценивать ее тоже не нужно.
Ты проживешь без королей? — Солдат сказал: Изволь!
— А ты без гвардии своей?
— Ну нет! — сказал король.
4. Не поверите, но с продажниками у меня полное взаимопонимание обычно, равно как и с разрабами -)
Имхо, продажник, без разработчика никому не нужен. Поиск хорошего разработчика занимает продолжительное время, а вот продажников нет, и их обычно вообще пачками нанимают.
Зависит от компании. Да, есть состоявшиеся на рынке крупные компании, и у них проблема, скорее, в хороших-разработчиках-за-мало-денег (не будем показывать пальцем на эти компании — их все знают), но если бизнес целиком и полностью зависит от эффективности работы отдела продаж, то хороший продажник, скажем так, не менее важен, чем хороший разработчик. Без продажника в этом случае хороший разработчик — бесполезен, к сожалению.
А можете в общих чертах объяснить, как именно нужно организовать процесс разработки, чтобы «разработчик низводился до уровня заменяемой в 1 день рабочей силы»? Разумеется, если речь идёт не о проекте-однодневке и не о сотруднике-джуниоре, который ещё ничего не успел понять и с тем же успехом заменяем на любого другого «студента».
Помнится, год-два назад была на хабре статья про индусскую (да-да) компанию, в которой архитектура продукта была выстроена таким образом, что программеры пилили крохотные независимые кусочки. И раз в год низовые программе менялись полностью — новые набирались по объявлению. Крайне успешный бизнес-процесс.
мне одному кажется что дворницкий диалект русского языка, изобилующий малопечатными эпитетами значительно улучшает понимание подобными персонажами сути проблемы?
Жутко бесит вот такая ситуация:
Клиент: «Мы обязательно купим ваш коробочный продукт на 100500 рабочих мест, но надо добавить еще это и вот это»
Продажник с нулями в глазах бежит к руководству, руководство ставит на уши разработчиков, те в кратчайшие сроки реализуют все что нужно.
В итоге выясняется, кто клиенту бюджет или совсем не выделили (чаще всего), или выделили на самый минимальный пакет, что никак не окупает потраченное время. Но продажник уже бежит с подобной вестью от следующего «клиента»
Клиент: «Мы обязательно купим ваш коробочный продукт на 100500 рабочих мест, но надо добавить еще это и вот это»
Продажник с нулями в глазах бежит к руководству, руководство ставит на уши разработчиков, те в кратчайшие сроки реализуют все что нужно.
В итоге выясняется, кто клиенту бюджет или совсем не выделили (чаще всего), или выделили на самый минимальный пакет, что никак не окупает потраченное время. Но продажник уже бежит с подобной вестью от следующего «клиента»
Классика жанра!
Забыл написать про такое.
Забыл написать про такое.
Это реально очень плохой продажник. Хороший ответит, что «вот это» будет стоить плюс столько-то денег и сколько-то времени и об этих «столько-то» будет одновременно торговаться с обеми сторонами — разработчиками и клиентом.
Ну а если и руководсво «ставит на уши» — то значит и оно не лучше.
Но согласен, увы — эо классика жанра.
Ну а если и руководсво «ставит на уши» — то значит и оно не лучше.
Но согласен, увы — эо классика жанра.
Речь о случаях, когда суммы различаются значительно, и, при условии оплаты суммы лицензий стоимостью разработки можно пренебречь (считаем, что делаем скидку на эту сумму) (если суммы сопоставимы, то это все-таки, как правило, отсекается на каком-то этапе). Но в итоге на выходе все равно ноль плюс подвинули по срокам какой-то другой проект
Есть еще классика жанра: «каждая команда разработчиков имеет тех продажников которых заслуживает».
Примерно год назад столкнулся с ситуацией:
Некий продажник из нашей аутсорсовой компании уберсрочно собирает всех старших фронтов. Судя по тону письма, предстоит пилить помесь фейсбука и ютрека и собственный фреймворк в придачу. На самом деле оказывается нужно для какой-то авиакомпании сделать виджет с бронированием мест — тупо какой-то вид плана сидений самолета с возможностью накликать нужные сиденья. Очень нужно, чтобы это легко откреплялось и прикреплялось.
Один из фронтов предлагает написать планигчик для jquery как в старые добрые времена. Продажник говорит, что этот вариант не подходит, нам нужно использовать Angular. Долгие попытки вразумления (ангуляр будет весить больше нашего кода на нем, его хрен открутишь итд) заканчиваются сакральной фразой «Я уже продал ангуляр».
Теперь использую ее в любой ситуации, когда далекий от технической стороны вопроса человек пытается проталкивать свои идеи по реализации. В другой компании.
Некий продажник из нашей аутсорсовой компании уберсрочно собирает всех старших фронтов. Судя по тону письма, предстоит пилить помесь фейсбука и ютрека и собственный фреймворк в придачу. На самом деле оказывается нужно для какой-то авиакомпании сделать виджет с бронированием мест — тупо какой-то вид плана сидений самолета с возможностью накликать нужные сиденья. Очень нужно, чтобы это легко откреплялось и прикреплялось.
Один из фронтов предлагает написать планигчик для jquery как в старые добрые времена. Продажник говорит, что этот вариант не подходит, нам нужно использовать Angular. Долгие попытки вразумления (ангуляр будет весить больше нашего кода на нем, его хрен открутишь итд) заканчиваются сакральной фразой «Я уже продал ангуляр».
Теперь использую ее в любой ситуации, когда далекий от технической стороны вопроса человек пытается проталкивать свои идеи по реализации. В другой компании.
Не очень понимаю, почему продажник продал «Angular»? По идее его задача принести в «клювике» Клиент ожидаете получить XYZ. Сколько стоит?
Какое его его дело как это будет сделано: кодом на Angular или хрустальный шар натрут кровью младенца в лунное затмение если это в рамках закона?
Какое его его дело как это будет сделано: кодом на Angular или хрустальный шар натрут кровью младенца в лунное затмение если это в рамках закона?
Я полностью согласен. И даже более того, любого заказчика можно адекватно убедить в том, что ангуляр не нужен, сказав «Знаете, мы посовещались с коллегами и решили, что дешевле будет обойтись без ангуляра. Парни сказали, что на ваниллу у них уйдет гораздо меньше времени [поэтому доплачивайте за срочность]». Но это просто бывают такие люди, на любых позициях и должностях. Синдром вахтера.
Отличный кейс, спасибо.
Кстати, планы самолётов — у всех отдельных экземпляров — разные, Чуть-чуть, но почти не встретить двух одинаковых (относительно окон, что самое важное во всём эом). А ещё АК (авиакомпании) — часто меняют борт под рейс в зависимости от (от много-много чего вообще-то), и по закону — не обязаны в этом ни перед кем отчитываться, даже при замене реактивного на трубопроп и беспосадочного перелёта на рейс с двумя пересадками (транзитные билеты и ещё нюансы. коих много, пока отложим)…
Кроме того — бывают места, например, у аварийных выходов, куда нельзя сажать детей, стариков, сильно толстых, инвалидов, немощных, беременных и т.п… Бывают места, куда возможно/удобно вешать люльку, когда и если она нужна — но это не каждый рейс требуется, но тоже не всюду можно повесить. и наоброт — есть места с широким проходом — туда посадят инвалида, Кроме того — кабинный экипаж (бортпроводники) имеют право и обязанность — пересадить пассажиров, если их текущая рассадка влияет на центровку (напр команда сумоистов села вся в хвост, а два класса детей — в нос)…
По этим граблям прошлось уже ОЧЕНЬ много прикладо/сайто-писателей, так что проект всё равно бы не получился, и вы правильно и вовремя с того корабля ушли.
Кроме того — бывают места, например, у аварийных выходов, куда нельзя сажать детей, стариков, сильно толстых, инвалидов, немощных, беременных и т.п… Бывают места, куда возможно/удобно вешать люльку, когда и если она нужна — но это не каждый рейс требуется, но тоже не всюду можно повесить. и наоброт — есть места с широким проходом — туда посадят инвалида, Кроме того — кабинный экипаж (бортпроводники) имеют право и обязанность — пересадить пассажиров, если их текущая рассадка влияет на центровку (напр команда сумоистов села вся в хвост, а два класса детей — в нос)…
По этим граблям прошлось уже ОЧЕНЬ много прикладо/сайто-писателей, так что проект всё равно бы не получился, и вы правильно и вовремя с того корабля ушли.
Да, познавательно, спасибо
«Нужно постараться»
Так и что же разрабы отвечают обычно на эту фразу продажникам?
Так и что же разрабы отвечают обычно на эту фразу продажникам?
Не реально, но мы постараемся.
Девять женщин за месяц не родят одного ребенка :)
или убирай фичи, или ищи ресурсы в следущем объеме или объясняй клиенту, что ты солгал…
В противном случае: «мы постараемся» трактуется как «вы же кровью подписались! вы виноваты», а у Клиента срабатывают бизнес риски.
Да и обычно «нужно постаряться» идет лично от продажника, ибо ему процент капнет «сейчас», как раз когда завезли новые айФоны :))
или убирай фичи, или ищи ресурсы в следущем объеме или объясняй клиенту, что ты солгал…
В противном случае: «мы постараемся» трактуется как «вы же кровью подписались! вы виноваты», а у Клиента срабатывают бизнес риски.
Да и обычно «нужно постаряться» идет лично от продажника, ибо ему процент капнет «сейчас», как раз когда завезли новые айФоны :))
хотел было отправить нашим (и тем и другим), но таки согласен с несколькими мнениями уж высказанными ранее — однобоко. Представьте, что продажники всегда общаются с разработчиками формулировками «Как правильно», дальше что? Например я сейчас очень часто слышу претензию со стороны продажников вида:
Сначала спросил у разработчиков, сколько займет реализация, мне сказали месяц. Пообещал клиенту «через пол года». Уже год прошел, где?! Что мне отвечать клиенту?
Рискуя быть заминсованым — «общение», это как минимум две стороны. Это значит, что учить нужно обе стороны. Нельзя считать, что «одна чторона уже ок». Есть же классическое «если программа работает не так, как написано в документации, значит ошибка и там и там». Если общение не складывается — виноваты оба.
Сначала спросил у разработчиков, сколько займет реализация, мне сказали месяц. Пообещал клиенту «через пол года». Уже год прошел, где?! Что мне отвечать клиенту?
Рискуя быть заминсованым — «общение», это как минимум две стороны. Это значит, что учить нужно обе стороны. Нельзя считать, что «одна чторона уже ок». Есть же классическое «если программа работает не так, как написано в документации, значит ошибка и там и там». Если общение не складывается — виноваты оба.
1. Ок, однобоко, я признаю, учту на будущее.
2. Обещали месяц, оказалось пол года — это типичная ситуация, которую мне постоянно приходится разруливать. Что там могло случиться? Не было ТЗ? Было ТЗ, но функционал изменился? Не было стартового контента? Изменились требования? В команде разрабов были замены? Никто такого раньше не делал? Всплыли неучтенные в ТЗ подводные камни?
Каждый раз в таких ситуациях мы стараемся решить не столько конкретную ситуацию, сколько понять что нам мешало и учесть это в будущем.
3. Да, общение это обоюдный процесс. И, да, мы имеем дело с конфликтной ситуацией. Она естественна, т.к. у разрабов и продажников слишком разные интересы, кто бы что здесь не писал.
Есть много академических книг по конфликтологии и переговорам, где дана теория, примеры и эффективные методики разрешения конфликтов.
Если бы я написал их обзор, было бы это интересно?
4. Кстати статья построена частично на одной из фундаментальных методик: «Поставить себя на место противоположной стороны». Это предлагается сделать продажнику. Предлагается задуматься над тем, как чувствуют себя и что думают специалисты в типичных ситуациях.
5. Эффект от статьи для меня немного неожиданный, т.к. разработчики стали ставить себя на место продажников, и писать мне, что я слишком несправедливо их обижаю.
6. Многие пишут мне про однобокость статьи, про общение, про учет интересов другой стороны, прямо как по учебнику. Это же прекрасно! Значит статья стимулирует к таким мыслям?
7. Удалось бы стимулировать такие мысли, написав все это в лоб?
8. С другой стороны некоторых важных целей я не достиг. Хотелось, чтобы статья была веселой и позитивной, чтобы можно было ее смело дать коллегам поржать. Позитив куда-то уплыл во время правок, сорри -)))
2. Обещали месяц, оказалось пол года — это типичная ситуация, которую мне постоянно приходится разруливать. Что там могло случиться? Не было ТЗ? Было ТЗ, но функционал изменился? Не было стартового контента? Изменились требования? В команде разрабов были замены? Никто такого раньше не делал? Всплыли неучтенные в ТЗ подводные камни?
Каждый раз в таких ситуациях мы стараемся решить не столько конкретную ситуацию, сколько понять что нам мешало и учесть это в будущем.
3. Да, общение это обоюдный процесс. И, да, мы имеем дело с конфликтной ситуацией. Она естественна, т.к. у разрабов и продажников слишком разные интересы, кто бы что здесь не писал.
Есть много академических книг по конфликтологии и переговорам, где дана теория, примеры и эффективные методики разрешения конфликтов.
Если бы я написал их обзор, было бы это интересно?
4. Кстати статья построена частично на одной из фундаментальных методик: «Поставить себя на место противоположной стороны». Это предлагается сделать продажнику. Предлагается задуматься над тем, как чувствуют себя и что думают специалисты в типичных ситуациях.
5. Эффект от статьи для меня немного неожиданный, т.к. разработчики стали ставить себя на место продажников, и писать мне, что я слишком несправедливо их обижаю.
6. Многие пишут мне про однобокость статьи, про общение, про учет интересов другой стороны, прямо как по учебнику. Это же прекрасно! Значит статья стимулирует к таким мыслям?
7. Удалось бы стимулировать такие мысли, написав все это в лоб?
8. С другой стороны некоторых важных целей я не достиг. Хотелось, чтобы статья была веселой и позитивной, чтобы можно было ее смело дать коллегам поржать. Позитив куда-то уплыл во время правок, сорри -)))
1. на всякий случай уточню: мнений «с одной стороны», по крайней вокруг меня, достаточно. И все правы, что характерно. Но конструктив получается при диалоге, когда смотрят на обе чаши весов, и находят тот самый баланс.
2. Обещали месяц, сколько получилось — уже не очень интересно, через год нет результата. Пол года — сейлз «накинул риски» уже сам, от себя.
Дальше все очень хорошие и правильные вопросы, но мы ведь пытаемся рассматривать общение «Разработка <> Сейлз»? И по крайней передо мной проблема именно в том, что «понять, что мешало».
Если вернуться в контекст статьи — понять, кто кому что должен говорить (и видимо в какие моменты времени), что бы
а) получать таки результат
б) всех оставались в хороших отношениях
Чаще всего, когда та самая точка баланса не найдена, появляется руководство, и выписывает всем. Что под руку попадется. Результат в итоге таки получают, но радости никакой, к сожалению ни у кого. Ни у заказчика, ни у руководства, ни у сейлзов и разработчиков.
3. Книги мало кто читает, увы. Плюс, книги чаще несут фундаментальные знания, которые после прочтения нужно осмыслить и научиться применять в жизни. Обзор — лично мне, да, однозначно интересно.
Но первое желание было кинуть ссылку коллегам, на хорошую статью, которая будет как-бы мини-книгой для одного конкретного прикладного аспекта.
Что-то типа «Как подружить разработку и сейлзов за 3 дня и выпускать умопомрачительные продукты» :)
Если есть силы-желание-время серию статей, на разные смежные аспекты.
8. Веселая и позитивная, кажется, может получиться если разработчиков и сейлзов поменять местами — обхохочешься %)
2. Обещали месяц, сколько получилось — уже не очень интересно, через год нет результата. Пол года — сейлз «накинул риски» уже сам, от себя.
Дальше все очень хорошие и правильные вопросы, но мы ведь пытаемся рассматривать общение «Разработка <> Сейлз»? И по крайней передо мной проблема именно в том, что «понять, что мешало».
Если вернуться в контекст статьи — понять, кто кому что должен говорить (и видимо в какие моменты времени), что бы
а) получать таки результат
б) всех оставались в хороших отношениях
Чаще всего, когда та самая точка баланса не найдена, появляется руководство, и выписывает всем. Что под руку попадется. Результат в итоге таки получают, но радости никакой, к сожалению ни у кого. Ни у заказчика, ни у руководства, ни у сейлзов и разработчиков.
3. Книги мало кто читает, увы. Плюс, книги чаще несут фундаментальные знания, которые после прочтения нужно осмыслить и научиться применять в жизни. Обзор — лично мне, да, однозначно интересно.
Но первое желание было кинуть ссылку коллегам, на хорошую статью, которая будет как-бы мини-книгой для одного конкретного прикладного аспекта.
Что-то типа «Как подружить разработку и сейлзов за 3 дня и выпускать умопомрачительные продукты» :)
Если есть силы-желание-время серию статей, на разные смежные аспекты.
8. Веселая и позитивная, кажется, может получиться если разработчиков и сейлзов поменять местами — обхохочешься %)
Сначала спросил у разработчиков, сколько займет реализация, мне сказали месяц. Пообещал клиенту «через пол года». Уже год прошел, где?! Что мне отвечать клиенту?
Разработчик в таких случаях отвечает про срок, если он всё бросит, начнет это разрабатывать, допустим, завтра и не будет других задач. Т.е. называет срок для расчета стоимости. Но это же не так — есть очередь других задач, и ближайшее свободное окно может быть только через год, либо постоянно задачи добавляются с более высоким приоритетом, поэтому ваша задача двигается, вот и всё. Т.е. диалог должен быть таким:
— Сколько времени потребуется на решение этой задачи?
— Месяц
— Когда сможете начать?
— Сначала закроем (список клиентов) и если не будет новых запросов от (еще список)
Но чаще продажник после ответа на первый вопрос уже убегает звонить клиенту
Сначала спросил у разработчиков, сколько займет реализация, мне сказали месяц. Пообещал клиенту «через пол года». Уже год прошел, где?! Что мне отвечать клиенту?
А вопрос «когда сможете сделать и представить Клиенту?» задавался? Если нет — то в чем претензии? Сам пообещал «через пол-года» сам сделал :)
Плохо, когда продажники перетягивают власть на себя. Но так же плохо, когда и программеры перетягивают власть на себя. В обоих случаях это окончилось срывами сроков, уменьшением продаж и постепенным отваливанием клиентов — конкуренты развивались быстрее, чем разрабы чесались(есть у нас такое, есть… нам дай волю — и сроки сдвинуться раза в два-три куда не надо...).
Поэтому, идеальный, и к сожалению, редко встречающийся, вариант в том, чтобы максимально разделить продажников и разрабов, сведя все к беседам с тимлидом(-ами).
Поэтому, идеальный, и к сожалению, редко встречающийся, вариант в том, чтобы максимально разделить продажников и разрабов, сведя все к беседам с тимлидом(-ами).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как научить продажника говорить с разработчиками