Archive for the ‘О большом и малом’ Category

История предыдущей фирмы (часть 5).

Четверг, Сентябрь 10th, 2009

С огромным перерывом возвращаясь к циклу статей (1,2, 3, 4) в которых я рассказывал о развитии моей с братом фирмы. Что радует, что статья эта последняя. Что не радует, что она гораздо менее радужная чем все остальные.

В прошлой статье я остановился на мае 2007 года.

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

Почему ушел заказчик? Хороший вопрос. Там много чего намешано было — то, что я был и сотрудником и владельцем provider’а и часовой пояс, и консолидация offshore активности и не слишком удачные с технической стороны последние несколько месяцев. Но, ключевым пунктом я бы сказал являлось то, что мы просто загнали себя в угол предоставляя им только Palm разработку(которая к тому времени была уже откровенно не актуальной).

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

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

Где-то в сентябре 2007 я приезжал в Украину и все еще давал речь о том, что хоть сеячас тяжко, но мы все еще движемся в светлое будущее. Хотя, мягко говоря, я сильно в этом сомневался.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А вот теперь к самому интересному. Что же все таки мы могли сделать?

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

И естественно я пытаюсь базировать все решения на нынешних знаниях, но тогдашних возможностях.

На данный момент я вижу три наиболее перспективных на тот момент пути

а)  Постепенный слив фирмы

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

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

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

Ясно, что с такой стратегией много с фирмы не получишь, но все равно больше чем в случае полного вылета.

б) Реорганизация

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

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

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

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

Такие вот размышления о событиях прошлого.

О тупых программистах.

Пятница, Январь 30th, 2009

Осторожно, очень много букв 🙂

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

Кстати,  именно он подкинул мне идею (был ее автором) самой моей любимой серии статей про программистский синхрофазатрон.

И вот, собственно, смирившись с невозможность победить в online споре, я решил перейти в offline режим, где смогу детализировано рассмотреть проблему.

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

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

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

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

Итак начнемс…

Приведу три точки зрения. Первая — точка зрения программиста, вторая точка зрения менеджера, третья — точка зрения предпринимателя.

С точки зрения хорошего программиста Пети. Работа выглядит так
— Васе дали задачу, которую Петя мог сделать за 5 часа
— Вася поморочил Пети голову 2.5 часа, чтобы понять как ее сделать
— Вася проработал над задачей 20 часов пока не сделал
— Пете еще 2.5 потом пытается привести в порядок, то что натворил Вася

— Качество результата вышло хуже, чем если бы Петя делал сам.

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

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

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

Менеджер мыслит примерно так (естественно не с такими детальными выкладками)

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

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

Кстати, входные деньги — это не только деньги на зарплату программисту, но и на например покупку книг, или оплату другому программисту время консультаций и т.п.

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

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

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

Небольшое замечание по измерению оценки. Программист оценивает других программистах в терминах «на» — Вася сделает туже задачу _на_ X долларов дороже чем я, поэтому Вася не нужен. Менеджер измеряет в терминах «в». Вася сделает туже задачу _в_ Y раза дороже.

Теперь следующий шаг в оценках менеджера. Пусть мы знаем, что задача которая подается программистам на вход должна принести скажем $10k. Самый эффективный программист на ее решение тратит $1k. Из этого следует, что все кто эффективны менее чем в 10 раз, будут тратить больше $10k и значит, что они приносят фирме уже только убыль. И чем больше они работают, тем большую убыль приносят. Так, что их таки можно увольнять.

Возвращаясь к Васе. Пусть Вася по этой формуле оказался в 4 раза менее эффективным. Тем не менее, с решенной задачи мы все еще имеем $10k — $4k = $6k прибыли.
Хотя безусловно, если Васю уволить, то получится $9k прибыли.

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

То есть, если у него эффективность жуткая (в 7 раз хуже, чем у Пети), но работает он автономно и Петю не трогает вообще, то тогда, получается, что они вдвоем могут приносить $10k-$1k (Петя) + $10k-$7k (Вася) = $12k. А если Васю уволить, то прибыль падает до $9k.

Ну и теперь с точки зрения предпринимателя.

Базируем ее на точки зрения точке зрения менеджера. Только введем некоторые дополнительные параметры.

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

Итого, когда у нас диапазон качества, в абсолютно условных цифрах от 3 до 5. То вполне возможно, Вася сделал бы задачу с качеством 3 с той же эффективность, которое Петя делает задачу с качеством 8 (с одной стороны такое качество просто и не нужно, с другой стороны Петю ругать за дополнительное качество тоже было бы странно, да и плюс именно из-за Пети в целом программа не выпадает из диапазона).

Заметьте, как мыслит программист

а) Берется факт о случившейся ситуации где эффективность другого программиста была низкая

б) Из факта делается индукция, что у программиста всегда эффективность низкая (индукция тут не совсем правильна, но в целом, конечно вывод получается правильный, что у программиста низкая эффективность)

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

На самом же деле расход и доход динамичен. Он происходит в разные моменты времени.

Вернемся к примеру, который привел программист. Если плохой программист тратит в одной точки времени 5 часов хорошего, 20 часов своих и после этого в какой-то момент получается прибыль $10k, то действительно второй программист паразитирует в прямом смысле слова.

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

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

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

Естественно, наиболее хороший и логичный ответ, что в фирму из 3 хороших программистов нужно нанять еще 3 и они по быстродействию (даже последовательному)  станут быстрее, чем 30 плохих программистов.

Тут кроется одна проблема, это хорошо масштабируется от 1 до 5 хороших программистов, плохо от 5 до 50 и не масштабируется фактически вообще от 50 до 500 программистов. Поэтому для увеличения прибыли и сокращения сроков, компании проще нанимать 50 хороших программистов и 500 плохих, чем 100 хороших.

И последняя особенность.  В формуле прибыль = доход — расход, и доход и расход на самом деле являются не константами, а функциями.

Во первых, если фирма имеет большие продажи, то тогда доход от одной и той же функциональности может быть разный. И вот возникает интересный эффект. Если доход $10k, при расходах $1k и $7k — то отличие хороших и плохих программистов очень чувствительно (так как это изменяет прибыли от 90% дохода до 30% дохода). А вот если доход составит $100k, то разница между хороших и плохим программистов фактически не чувствуется (99% или 93%).

Важное замечание, которые мне написали: Это естественно более актуально для продуктов, где прибыль зависит от объема продаж. Для попроектной работы, прибыль заранее фиксирован. Более того, чаще всего они сильно прижат конкуренцией за исполнение проекта.

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

Фух… Подводя к итогам всю эту фигню, которую я написал.

а) Идеальная ситуация — много хороших программистов, нету плохих. Ситуация идеальная, но недостижима из-за плохого масштабирования найма хороших программистов.

б) Из-за пункта а) и больших штрафов при более позднем выпуске продуктов, компаниям выгодно распараллеливать работу нанимая средних и плохих программистов.

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

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

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

Вера в лидеров и бабки.

Воскресенье, Январь 4th, 2009

И еще одна из незаконченных статей.

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

Так вот, по поводу этого, у меня пару «за» и пару «против».

Начну очень издалека.

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

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

Теперь прыгаем к примеру с продавшицой. Пусть есть магазин в котором объем продаж $5k-$10k и в нем сидит продавщица, которая «отрываясь» на клиентах отбивает их от магазина и приближает продажи ближе к $5, а не отрываясь она приближает их к $10k. У нее же самой ЗП, может быть вполне $200. Стоит ли ей платить больше (есть на рынки именно такие цены). Я бы сказал, стоит если она старается, если же она требует это пытаясь держать вас в заложниках того, что ваша прибыль упадет на $5k, то ее надо гнать в шею, как того работника который просил повысить ЗП, чтобы он не работал плохо.

Смотрим дальше, предположим из-за ново нанятой продавщины, просто отбоя в магазине нету, вероятнее всего ей можно и $500k и $1k поставить зарплату (гораздо выше средней по рынке), если продажи зашкалили за $15k.

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

А теперь, какое это к черту имеет все отношению к лидерам?

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

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

Еще дальше возвращаясь, к статье Макса. Так вот, с чем я НЕ согласен, что роль лидера преувеличена. Да, CEO не решает все в компании (как Макс писал, статистически 10% успехов компании может быть отнесены к действиям CEO). С другой стороны, если 10% успехов увеличивают в 10 раз прибыль, то можно и в раза два зарплату им выше держать.

Как я писал, статья лежала в загашнике и честно говоря я не совсем понимаю к чему я тогда вел 🙂 Так что приведу чуть другую схему аргументировка.

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

Тоже самое в компаниях. Да, лидерство не так важно, когда все идет хорошо. Но когда все идет плохо, то лидерство — это единственное, что может спасти компанию. Поэтому, как по мне роль лидерства не преувеличена, а просто не правильно акцентировано внимание, когда же его роль действительно важна.

О выходе на больших игроков рынка.

Среда, Октябрь 29th, 2008

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

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

Так вот, это ошибка звучит в бизнес плане примерно так: «… и вот тут мы пообщаемся с крупными фирмами…».

Проблема заключается в том, что крупные фирмы ежедневно получают десятки, а то и сотни разных email’ов и звонков с разнообразными идеями и предложениями. И дай бог 1% из них доходит до стадии серьезного планирования, до стадии исполнения доходят 0.1%, а до стадии денег 0.01%.

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

Соответственно, для этого,  нужно:

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

б) Sales должны быть достаточно зубатыми, чтобы суметь вставить ногу в дверь, перед тем как захлопнут перед ними дверь.

Исходя из пункта а) + б) — в этих sales нужно будет вкладываться. Причем, не $100/месяц наняв девочку где-нибудь черт знает где, которая умеет слегка говорить, а вполне придется вкладывать взрослые цифры в взрослый sales.

Учитывая, что под крупными фирмами вероятнее всего подразумевается, что-то зарубежное и серьезное. То в добавок, sales должен иметь опыт работы с такими фирмами и иметь возможность подъехать и лично пообщаться в эти фирмы.

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

Естественно, всегда есть пару «но». Идеально, если вы или кто-то из партнеров уже имеет интересные контакты в  таких фирмах. Это не просто плюс, это три плюса на фюзеляже. Ну и очень хорошо, если вы, не программист, а sales, так как тогда вы сможете сами стучаться в закрытые двери.

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

Одно замечание, большие фирмы вполне могут купить у вас N копий продукта. Но купить копию и сотрудничать (или купить всю вашу фирму) — это совсем разные вещи.