Ну, пока еще не начал, хочу упомянуть блог Романа Кононова о QAлификации.
На самом деле, статья — это мой вопрос вам. Как вы считаете, почему создание продукта такое сложное дело?
Вроде, когда с чем-то играешься и делаешь для себя, то за недельку собираешь очень даже мощную вещь, а вот как только нужно что-то сделать для выпуска в белый свет, то обнаруживаешь, что полгода бьешься над махоньким продуктом.
Что скажете по этому поводу?
Все таки, забавная вещь продуктовая часть IT бизнеса. Вот, раздумываю тут на темы — насколько правильно или неправильно я выбрал идею и вообще можно ли правильно ее выбрать.
Забавность состоит в том, что есть две крайности, в которых нельзя впадать.
С одной стороны, нужно верить в свою идею, что бы не говорили другие, так как всегда найдутся люди которые придумают какую- какашку кинуть в сторону вашей задумки.
С другой стороны, нужно слушать окружающих людей и принимать их критику, так как в конце концов, продукт таки понадобиться продавать и если людям он не нравиться уже сейчас, то может и не понравиться потом.
Вот тут и получается, что заваливаясь в любую крайности — либо получаешь продукт, которые никому не нужен, либо отбрасываешь хорошую идею, только из-за того, что боишься, что она провалится.
А еще забавно — это смотреть не вперед, а назад. Действительно, когда только начинаешь делать продукт, то все то что впереди непонятно/неизвестно и затянуто туманом. Но с другой стороны, можно легко посмотреть назад и четко видеть путь пройденный другими компаниями и из этого делать вывод.
Вот например, так компания в которой я работал, эдак лет с 10 назад сделала маленькую утилитку для выборочного шифрования файлов на SD карточке для Palm. Ну, что, какой потенциал у этой идеи? Я думаю все скажут, что откровенно маленький.
А теперь глядим дальше. Где-то 8-9 лет назад она эту утилитку расширила и сделал небольшую программу для Palm, которая позволяет шифровать данные и на устройстве и на карточке, плюс показывать пароль. Уже конечно лучше, но, программа продается по $20 на сайтах а-ля Handango и тоже пока не слишком выглядит мощной.
Движемся дальше, и где-то лет 7-8 назад, количество функциональности нарастает — появляется пароли на отдельные программы, запрещение использования IR портов, добавляется Desktop часть по управлению настройками (что разрешать, что запрещать). Уже звучит еще более интересней.
Где-то еще через год — появляется WinMobile версия. Количество функциональности и количество поддерживаемых телефонов ползет вверх. Понемногу все это начинают продавать небольшим компаниям (то бишь оптом, а не в розницу).
Далее, где-то 5 лет назад в эту смесь добавляются венчурные капиталисты, которые вливают деньги в компанию и перестраивают ее на путь enterprise mobile security. Продукт перестает продаваться в розницу и переходит чисто на опт. При этом все продолжают расти количество функций и количество поддерживаемых устройств.
Следующие где-то два года идет бег на месте, так как на рынки мобильных платформ большой сдвиг. PalmOS с четвертого перешел на пятый, вышел WinMobile 5.0 и компания просто гребет против течения, чтобы не унесло в открытое море. И где-то три года назад, компания переходит с режима центральная программа Desktop, на центральная программа в Web, плюс появляются возможность централизованного просмотр информации о том, какие устройства защищены, а какие нет, функции по удаленной работе с устройствами.
И где-то в течении прошлых лет трех, парадигма меняется с режима «шифрование на устройстве», на «управление безопасностью мобильных устройств в компании». Соответственно, заказчики уже не мелкие голожопики, которые покупают по 1-3 копии, а серьезные фирмы, которые покупают продукт очень крупных оптом. Плюс, к этому времени уже очень много компаний обеспокоины тем, что потеря мобильника с 4Gb памяти с кучей почты содержащей конфиденциальную информацию ни чем не уступает уже потери notebook’а.
А теперь, возвращаемся назад — утилита для шифрования SD карты для Palm и продукт с десятком разных программ, работающий на многих платформах, который занимается управление безопасностью для мобильных устройств всей компании. Ведь, сразу понятен абсолютно разный размах и перспектива. А ведь на самом деле — это одна и та же компания.
Так что, третьим пунктом, который бы я добавил к тому, что нужно верить в свою идею и нужно прислушиваться к окружающим, является то, что вероятнее всего ваша идея не идеальна и как раз самое главное вырастить ее из зернышка задумки в большое растение серьезного продукта.
Давно хотел написать о том, как по моему мнению должна быть построена иерархия в компания.
Но, как точно заметил СОТОНА, на идеальный пост времени нету.
Так что буду потихоньку эту тему раскапывать.
В общем ситуация следующая. Неправильная иерархия для компания, делает тоже самое что неправильная архитектура для программы. То есть при неправильной иерархии вроде и все работать
может, но сбоит по черному и непонятно откуда у проблем растут ноги.
Итак, сначала покажу схемку, которую я набросал пару месяцев назад. Сразу скажу, что могут быть какие-то огрехи, но главное я хотел передать идею….
Итак, вот она схемка. Схемка того, как должна выглядеть продуктовая контора или продуктова/сервисная. Впрочем даже сильно сервисная может так тоже выглядеть, но с небольшими модификациями.
А теперь, о том, что я имел ею в виду
— Первое и самое основное (того, чего в схемке не указано). У каждой позиции должен быть четкий список обязанностей и ответственности. Директор по продажам не должен садиться подпедалить код,
а технический менеджер не должен мотаться по всему миру собирая у заказчиков требования.
Я кстати об этом писал в статье «О разделении обязанностей между технарями и продавцами.»
— Второе. Это размер фирмы. Естественно, нарисованная фирма скорее выглядит как что-то эдак размером человек 500. Скажем так, многие из этих должностей могут быть объедененны в одном человек для небольшой фирмы. Главное, что можно объеденять должности внутри одного подразделения, но не между ними.
То есть может быть и программист и главный программист в одном лице. И product manager с business director’ом в одном лице. Но уж никак не главный QA и sales director в одном флаконе.
Теперь можно уже и по структуре. Основное, с чего я вообще начал рисовать эту схему с Product Manager’а. Звучит конечно смешно, но это самый главный человек в компании. C одной стороны он находится достаточно низко в структуре, чтобы влиять на детали, с другой стороны достаточно высоко, чтобы выбирать направление. В этому его уникальность и ценность одновременно.
Итак, самая основная его идея в том, чтобы собирать все хотелки сверху (от CEO, от Sales (это скорее сбоку)), идеи о том куда двигаться в будущем (от маркетинка), крики и плевки от заказчиков (через отдел support’а) и пинки от engineering’а. После того, как все собрано — все приоритезируется и выдается вниз engineering’у на исполнение и вверх отчетность о приоритетах.
Замечу, дальше в зависимости от удачности или не удачности приоритезации именно product manager’ов (включая business development director) должны либо гладить по голове, либо гладить утюгом.
То есть к ним идут все ниточки входных сигналов и от них идут все ниточки выходных сигналов. Еще раз замечу, не к CEO, а к ним.
Теперь, расходимся от них концентрическими кругами.
В случае если product manager’ов несколько — то Business Director как раз должен руководить, тем чтобы ниточки по нужным направлениями шли к нужному product manager’у и в ответ выходили нужные ответные сигналы.
Кстати, замечу, что если входные сигналы имеют право быть аналоговыми (то есть в достаточно произвольной форме), то выходные сигналы — все должны быть очень цифровым (четкий формат в виде документа с требованиями для инженеров, документа с планом и сроками для sales и т.п.)
Движемся дальше. Когда сигнал опускается до director’а engineering’а — то он обычно заключается в крупных проектах и это уже его дело разбить это напроекты поменьше, раздать менеджерам проектов х контролировать и т.п. В общем-то director engineering’а и project manager’ы это как раз те самые менеджеры среднего звена о которых я писал уже несколько раз.
Дальше движемся вверх по схеме. CEO по большему счету должен быть нужен в фирме для трех вещей
а) В случае наличия инвесторов — общение с ними
б) В случае если он основатель и задумщик идеи — он должен кормить этими идеям product manager’а. Хотя в идеале, тогда он должны перейти на должность Business Development Director и отдать руль CEO кому-то другому.
в) В случае если какая-то ветка работает плохо, разобраться в причине и уволить ее.
Ну и плюс сюда можно приписать воодушивительные выступления перед фирмой.
По большему счету это все, за что он должен отвечать
To be continued…
P.S. Круто… Первая картинка в блоге 🙂
Короткая заметка.
Я когда-то писал статью, как выбрать продукт, который стоит делать. Так вот, найти 8 положительных пунктов может каждый дурак, когда ему хочется что-то написать.
Но, перед тем как начать делать продукт, найдите в нем пять недостатков. Причем не для отмазки, а именно настоящих 5 недостатков. Если вы их не можете найти сами, спросите друзей… потом врагов.
Только после того, как вам хорошенького «подгадили» идею, раскритиковав ее достаточно, то тогда уже взвешивайте «за» и «против».
P.S. Кстати, идеальных продуктов без недостатков в идее, просто не существует.
