Archive for the ‘Продукты’ Category

Эффект забытого зонтика.

Вторник, Март 4th, 2008

Увидел забавный эффект. Когда на сцену вышел Google, все начали писать новые поисковые системы, когда человек сделал Million Dollar Home Page, все начали делать свои такие же страницы. Когда появился Facebook, все начали клепать социальные сети.

О чем это я… Ах да. Так вот, фактически никто из подражателей не получил и 1 цента прибыли.

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

Это я к тому, что когда вы читаете как гарантировано заработать денег (пиша plugin’ы по Facebook или разрабатывая web 2.0 магазины), то на самом деле — это значит, что на этом заработать уже нельзя.

P.S. Добавление и разъяснение. Все бросились штурмовать то, что есть удачные подражатели. Я с этим не спорю — таки есть удачные подражатели, однако вероятность выживания в не слишком занятой нише 5%, вероятность выживания в занятой нише скажем 1%. Один из методов, повысить свою вероятность выживания, копировать, но позиционировать для другого рынка (например русскоговорящий vs. англоговорящий).

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

P.P.S. Пожалуйста прочитайте мое пояснение к этой статье тут: «Либо встречу, либо нет«.

Не позволяйте планке падать.

Пятница, Январь 18th, 2008

При разработке продукта всегда есть всего два больших направления, которые тянут на себя время и ресурсы:

Написание чего-то нового

Исправление чего-то старого

Чаще всего, когда вы (или любой другой разработчик) делаете одно, то вы (в тот же момент времени) не делаете второго.

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

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

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

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

О разделении обязанностей между технарями и продавцами.

Среда, Январь 9th, 2008

Похоже мысли в интернете ходят парами. Где-то в декабре я написал заготовку для статьи и тут меня опередили, написали фактически тоже самое. Вот вам и «тю…».

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

Зачастую технические и менеджеры по продажам это забывают.

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

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

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

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

Нафига козлу баян или для чего вы вообще ваша фирма выпускает продукт?

Воскресенье, Декабрь 23rd, 2007

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

Естественно, этот документ должен быть «живым». То еcть на него не нужно молиться по утрам и он не должен быть высечен в камне подобно заповедям. Скорее, такой документ должен переглядываться, раз в пол года или год.

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

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

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

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