Похоже мысли в интернете ходят парами. Где-то в декабре я написал заготовку для статьи и тут меня опередили, написали фактически тоже самое. Вот вам и «тю…».
Обязанности и отчетность у технарей и продавцов в фирме должна быть четка описана. Ведь генералу не имеет смысл бросаться в штыковую атаку, а солдату нельзя доверить управление всей армией.
Зачастую технические и менеджеры по продажам это забывают.
Безумное количество раз я слышал (и попадал) в ситуацию, когда продавцы с довольным лицом приходят к технарям и говорят… Ребята, мы только что заключили потрясающую сделку, и все, что вам нужно к завтрашнему утру это сделать. Дальше идет непереводимая игра слов, когда технари пытаются объяснить, что им придется делать это год, а не день как считали продавцы.
Обратная ситуация, когда гордые технари, приходят к продавцам и говорят, что оно сделали мощную систему, которая решит все проблемы всех заказчиков. Как оказывается дальше, технари в жизни не видели ни одного заказчика, и о их проблемах и слыхом не слыхивали, но тем не менее, система по их мнению должна решить все проблемы.
В общем, кесарю – кесарево. Продавцы и маркетологи должны определять что нужно и будет нужно заказчикам/покупателям. Естественно имеет смысл послушать идеи технарей, но скорее в консультационном виде, чем в виде готовой системы (на которую уже потрачены деньги). И с другой стороны, когда речь идет о сроках выполнения и сложности задач, то технари должны решать сколько это займет, а не менеджеры по продажам.
Естественно, в конечно итоге, все это должно обсуждаться. И замечу, для того, чтобы все шло по разумного графику, поступки должны быть с обоих сторон — продавцы, должны совладать с своей жаждой иметь идеальный продукт, а технари с жаждой иметь бесконечность времени, для создания этого идеального продукта.
да, на 120% согласие с мнением что технари и маркетологи должны быть обоюдосогласованосработаны и работать командой — дабы все было более-менеее гладко и без «приятных» сюрпрайзов 🙂
2Helen: Да уж, неразделенные обязанности между продавцами и программистами дают множество «приятнейших» сюрпризов 🙂
типа ….левая не знает чего делает правая…да еще и «думалка» думает сама-по-себе: никак ни в такт да и бессвязно-disconnectedly с обеими…
это вот еще можно сказать и о руководстве — которое также должно вразумительно давать знать-понимать чего да и как предстоит и на что движение направлено «корабля» — работать и с маркетингом и с технарями
Со стороны (и только со стороны) несколько забавно смотреть на продавцов из vendor. Ведь начальники им уже сказали — наш продукт «идеальный» в инженерном смысле.
2Vladislav Artukov: Извиняюсь, я не совсем понял, что имелось в виду.
Будучи vendor’ом забавно смотреть на продавцев или забавно смотреть на продавцов, которые явлюятся vendor’ом? В чем состоит забавность?
2Helen: Да, как только части рассинхронизируются, то мгновенно фирма начинает тратить деньги на бесполезные вещи (либо ненужный development, либо на sales, которые не могу продать продукт).
Мне кажется что мысль уж слишком очевидная, что бы делать про это отдельный пост, тем более что не один год обсуждается.
Интереснее было бы послушать про фактические методы, каким образом можно решать проблемы такого рода…
2pnv82: Да, мысль вполне очевидная. Я думаю, вообще есть мало таких вещей, которые можно сказать, чтобы все упали и сказали… Как же я этого не понимал всю жизнь.
Решение проблем достаточно просто — бить по рукам, когда VP sales, VP marketing и VP engineering начинают лезть в чужую область деятельности.
Я видел несколько фирм, с неплохим финансирование и размером в которых постоянно выходили ситуации описанные в статье, когда лезли не в свои дела.
да….когда «лезут» не в свои — это чревато. Зачастую не понимая, а только разрушая да еще свое не выполняют толком. Это пересекается со статьей — когда неплохо, а скорее идеально чтобы все знали свое место а еще и «шарили» тоесть имели понятие о процессах других звеньев в производстве-разработке-выполнении чего-либо что касается продуктов и задач. Не говорю конечно что все работники должны быть универсальные многостаночники, но все ж таки должны иметь понятие реалий производства. Мне так кацца…
и по поводу еще «лезть» — должны понимать советоваться и ориентироваться — работать командой.
А по-поводу «…фактические методы, каким образом можно решать проблемы такого рода…» — ответ явный и описан хорошо 🙂 а там — уж как и кто его применяет
Да-да. А посередине находится кастомер менеджмент, который с клиентом потом разруливает проданное продавцом и натехниченное технарем:)
2Helen: Да, важно понимать, не только то, что делаешь ты, но и что делают другие.
2Anna: Да, менеджерам по работе с заказчика (обычно те что на support сидят) достается по полной программе.
[…] уже задевал эту тему в статье “О разделении обязанностей между технарями и продавцам…“, но тут копнуcь слегка […]
Этот пост можно бы было свести к единственной ссылке на эту емкую и короткую статью.
[…] — Первое и самое основное (того, чего в схемке не указано). У каждой позиции должен быть четкий список обязанностей и ответственности. Директор по продажам не должен садиться подпедалить код, а технический менеджер не должен мотаться по всему миру собирая у заказчиков требования. Я кстати об этом писал в статье “О разделении обязанностей между технарями и прода
«продавцы, должны совладать с своей жаждой иметь идеальный продукт, а технари с жаждой иметь бесконечность времени, для создания этого идеального продукта.»
В моей реальности это не так. Наши продавцы имеют жажду получить как можно больше денег, а наши программисты — создать продукт, который как можно больше меняет мир к лучшему. В результате появляется два видения идеального продукта, причем видение продукта продавцов «почему-то» стабильно сосет по сравнению с видением технарей.
В смысле «стабильно сосет»?
В смысле хуже продается? Не такой забавный или что-то другое?
В том смысле, что не меняет мир к лучшему.
К примеру, в тех рынках, где унификация играла бы на руку всем пользователям, она не происходит из-за технически необоснованных несовместимостей. Смотри штекеры зарядных устройств сотовых телефонов и розетки домашней электросети в разных странах как негативные примеры; и штекеры USB и протокол TCP/IP как более позитивные примеры.
К примеру, искусственно ограничивается область применимости выпущенного продукта (в софтописании за счет невыкладывания исходников и использования private, internal и sealed в API библиотек) с тем, чтобы фирма имела возможность заработать в будущем, заняв и другие области.
Так или иначе, продукт в случае успеха занимает сильно меньшую часть рынка, которая еще достаточна, чтобы достигнуть цель «заработать денег», но недостаточна, чтобы продукт получил культовый статус (а это цель программистов, потому что только тогда их стоимость на рынке труда ощутимо растет). Т.е. цели сейлсов занижены по сравнению с целями программистов, а не наоборот, как в статье.
Насчет, того, что программисты такие белые и пушистые, что хотят обязательно менять мир к лучшему… Я бы сказал, что это не так.
Большинство программистов относятся к работе — как к работе. В лучшем случае они хотят работу сделать хорошо.
Хотя я согласен, есть программисты желающие менять мир к лучшему. Но все же больше тех, которые просто хотят просто хорошо сделать то, что им дали. А еще больше, тех кто ничего не хотят.
Вот именно поэтому я люблю организационные структуры с динамическим распределением ответственности.
К примеру, MSF. В каждом продукте в каждый момент времени есть только один product owner, который двигает его вперед. Кто конкретно из руководителей команды (PM, Dev Lead или Test Lead) является product owner, решается для каждой конкретной команды, в том числе и в зависомости от того, кто из них больше хочет менять мир к лучшему. Я так понимаю, что шапка product owner может даже передаваться с течением времени — по обстоятельствам.
Другая известная имплементация этого принципа — демократический общественный строй. В каждый момент времени есть один конкретный главнокомандующий. Который меняется в зависимости от обстоятельств.
То, что вы описали — это как я понимаю очень близко к Scrum. Короткие участки времени — product owner, который двигает вперед и потенциальная смена product owner’ства в течении времени.
Насчет динамического разделения ответственности. Я думаю это неплохо должно действовать в том случае, когда продукт и компания очень сильно меняется/мигрирует. Тогда важная скорее гибкость, чем устойчивость.
Но, в тот момент когда компания стала на рельсы и ей нужно набрать максимальные обороты, динамические ответственности — будут не эффективные. Люди просто в конечном счете буду забывать, за что же они отвечали.
iphone case
iphone cover
iphone cases
iphone covers
iphone 4 case
iphone 4 cover
iphone 3GS case
iphone 4 cases
ipad case
ipad 2 case
ipad 2 cover
Shox pas cher
Basket Nike Pas cher
Air Max pas cher
Nike Air Max pas cher
Air Max 90 pas cher
Nike Air Max 90 Pas cher
Nike pas cher
Air Max 90 pas cher
Chaussures Nike pas cher
ED Hardy Clothing
Christian Audigier
ED Hardy Bags
ED Hardy Handbags
ED Hardy Shoes
ED Hardy T shirts
ED Hardy bikini
Cheap Ed Hardy
ED Hardy
Nike pas cher
Air Max 90 pas cher
Nike Air Max 90 pas cher
Nike Air Max pas cher
Nike Shox pas cher
Basket Nike Pas Cher
Air Max pas cher
Air Max 90
Nike Air Max 90
Nike Air Max
Nike Air Max 95
Air Max
Brian Atwood
Atwood Brian
Brian Atwood Shoes
Atwood Pumps
Brian Atwood Pumps