По заказам телезрителей разбираем откуда растут ноги у проблемы, что все хочется делать самому (вместо делегирования).
Сразу предупреждаю. Вышла длиннейшая и нуднейшая мутата 🙂 Так что, читать только в случае крайней необходимости.
Вот что писал Young и Vitali.
Переход от shareware продукта, в котором ты все делаешь сам или аутсорсишь куски, которые опять же ты выделил и проверил сам, в полноценный отчуждаемый бизнес который может рабоать без тебя.
Как преодолеть такую грань мышления, что нужно все делать только самому, т.к. нанятые работники сделают хуже? Как осуществить переход от фрилансера до управленца?
Начну с несколько побочных вопросов, а дальше уже перейдем к делу. В той самой книге RTFM (которую я упоминал), был описан один забавный случай: Человек видит на обложке журнала фразу «Как стартовать свой бизнес без проблем?», купил журнал, открывает и видит большую надпись на весь разворот «НИКАК».
Так вот, относительно «который может работать без тебя». Малый бизнес НЕ может работать без владельца. Максимально, на что можно надеяться, настроить его так, чтобы он мог проработать некоторое время (неделя, месяц, пол года). А все эти штучки-дрючку Киосакиевского разлива (а-ля создать себе пассивный источник дохода), можете выкинуть из головы прямо сейчас. (Кстати, вот мое мнение по поводу Киосаки).
Вторая побочная вещь, которую я хотел описать — это необходимость выделять какую-то работу. По большему счету, единственный случай, когда вам надо выделять работу — это когда у вас работы больше чем вы можете справиться и при этом за дополнительную работу потенциально вы получите положительную прибыль. Я специально сказал потенциально, так как для продуктового бизнеса вы зачастую вкладываетесь в послезавтрашний день и прибыль достаточно виртуальна в момент выполнения работы.
Теперь возвращаясь к проблеме.
Думаю, очень многие думают примерно такие мысли «Я — эту задачу могу сделать быстрее, лучше чем любой кому я ее дам. Причем, если я кому-то ее выдам, то мне придется за это еще заплатить, потом контролировать, чтобы все вышло как надо, объяснять как и что переделать, а зачастую по окончанию переделывать самом. Таким образом я больше времени потрачу на объяснения, контроль и переделки чем если сделаю это сам… Ура-ура… Я таки сам буду делать эту задачу.»
Как обычно, разделяем проблемы на подпроблемы. Хотя они безусловно пересекаются и именно их микс ступорит мозг
1. Я сделаю это задачу лучше чем другие (читай — выше качество и быстрее по времени, в целом эффективнее и дешевле)
2. Мне придется платить за выполнение задачи (жаба давит).
3. Мне придется контролировать исполнение, давать задачи и просить отчеты ( выполнять нетипичную, плохо понятную и неприятную работу).
4.Я потрачу больше времени на объяснение, контроль и исправления чем сделать задачу самому (опять же — эффективнее).
Идем по пунктам. Сначала разберемся кто виноват, а потом, что делать.
1. Я сделаю это задачу лучше чем другие (читай — выше качество и быстрее по времени, в целом эффективнее)
Скажем у нас есть директор компании в 100 человек. И он просто нереально крутой программист и может пофиксить баги быстрее всех. Стоит ли ему НЕ ехать на подписание 10 миллионного контракта, а вместо этого очень эффективно пофиксить баги?
Хитрость состоит в том, что локальная эффективность (на одной задаче) не значит глобальная эффективность по всей фирме. Именно из-за стоимости потерянных возможностей (контракта) директор описанной компании в здравом уме не будет фиксить баги.
Слышу уже голос из зала «Но, блин, я же не директор компании на 100 человек и подписание контракта в 10M у меня сегодня нету. У меня нет стоимости потерянных возможностей». Так, вот, если все время фиксить баги и педалить код — стоимость ваших потерянных возможностей — это то, что вы никогда не найдете новых контрактов, не продадите ваш продукт, не станете директором этой самой компании из 100 человек. Вы же пишите код, а не разбираетесь в том, как продавать продукт/работаете с людьми, которые дадут отзывы на ваши услуги, ездите на встречи на которых может завязаться знакомство принесущее новый контракт. Вообще, усердное программирование один из самых потрясающих методов убить все потенциальные возможности.
Вообще, положа руку на область желудка, программирование в IT бизнесе имеет примерно такую же важность, как вождение грузовика в доставочном бизнесе. Да, без программистов (водителей) не обойдешься, но в результате sales и marketing рулят и бибикают.
Так что, может быть дать задачу человеку, который сделает ее чуть медленее, а в этот момент, доделать web site, написать документацию и попытаться найти покупателей, на ту байду, которая пишется?
4.Я потрачу больше времени на объяснение, контроль и исправления чем сделать задачу самому (опять же — эффективне).
Вот с этим все обстоит сложнее. И так и так вы считаете, что вам придется тратить время.
Однако, тут важно остановится, положить руку на область желудка и признаться себе в двух вещах
— задачи с которыми знаком и которые нравятся обычно недооцениваются по времени
— задачи с которыми плохо знаком и которые не нравятся оцениваются слишком высоко.
Именно из этого и выходит, что-нибудь в виде: » … да я этот графический редактор я сам напишу за 2 дня, а вот если мне придется объяснять и контролировать, то у меня на это уйдет 2 недели».
Так, что тут желательно таки честно взглянуть и оценить, сколько может уйти времени на исполнение, а сколько на контроль. Относительно «придется все доделать и исправлять» — чуть позже напишу. Кстати, если на контроль выполнения у вас уходит больше чем несколько процентов (ну скажем 5) от времени исполнения, то это значит, что контроль вероятней всего тоже надо делегировать и контролировать того, кто занимается контролем.
3. Мне придется контролировать исполнение, давать задачи и просить отчеты ( выполнять нетипичную и неприятную работу).
Да — придется. И к этому надо привыкнуть.
Бизнес — это не сладкая река в которой можно делать только то что хочется (педать сверхмощную архитектуру для никому не нужного проекта).
Однако из приятного, после того, как вы двадцать раз сделаете что-то непонятное, непривычное и может даже неприятное (а-ля контроль чужой работы) — оно станет гораздо понятней и привычней (есть даже шанс, что приятней).
Я уже писал о том, что бизнес не хиханьки-хаханьки. Если вы собираетесь заняться бизнесом, то вы в первую очередь должны заботиться о деньгах, а только во вторую о остальных параметрах работы/бизнеса.
Такс… Много уже текста написал, а толком ничего не сказал. Так, что перейду таки к пункту что делать.
а) Нужно выбирать самые выгодные (приносящие максимальную прибыль с точки зрения бизнеса дела и делать их в первую очередь. Чаще всего порядок важности следующий — анализ финансового положения и планирование, работа над продажами, работа над организацией разработки, разработка.
б) Нужно начать делегировать и учиться на ошибках. Делегирование состоит из 3 частей — подготовка задачи (цель, требования, сроки, отчетность), контроль в ключевых точках и корректировка, принятие задачи.
Замечу, что фактически все руководители (включая меня) страдают тем, что один из этих пунктов выпадает.
Первая классическая ситуация (плохая подготовка задачи) — «Вася, пойди выкопай яму», потом обнаруживаем, что он выкопал ее не в том месте и не той глубины и не в те сроки.
Вторая классическая ситуация(плохой контроль в ключевых точках) — «Вася, яму надо выкопать метр, на метр, на метр, к следующему понедельнику (через неделю)». Через неделю привозим цемент заливать в яму, а ямы-то и нету, так как Вася забухал. А мы не удосужились потратить 5 минут выглянуть из окна, как движется яма.
Третяя классическая ситуация: «Вася, яму надо выкопать метр, на метр, на метр, к следующему понедельнику (через неделю)». Пришли поглядели в четверг и в пятницу, что яма продвигается. В понедельник обо всем забыли, во вторник тоже и через где-то месяц навернувшись ночью в эту яму начали возмущаться… какого фига тут выкопана яма.
Есть еще четвертый пункт, но он относится не впрямую к делегированию, а вообще к стилю ведения дел. Обязательно иметь полный список все дел, которые нужно сделать самому и которые были выданы окружающим (можно в электронном, но я рекомендую в бумажном виде — об этом в отдельной статье). Если у вас нету полного списка дел, вы не можете контролировать, так как вы просто не будете помнить, кто и что должен делать.
в) Собственно говоря, дальше вам нужна практика.
Начинайте давать, сначала небольшие задачи и четко приходитесь по пунктам — подготовка задачи, промежуточный контроль, финальный контроль. Собственно говоря, на этом этапе просто нужно выявить свои слабые места. Кому-то хочется побыстрее послать задачу (толком ее не сформулировав), кому-то не хочется держать руку на пульсе или проверять насколько хорошо сделано в конце. Боритесь с своими слабостями. Ваша сегодняшняя слабость превратиться в слабость вашего бизнеса завтра (можете почитать историю моей фирмы, там я расписал, как это произошло)
в) А как же вера в кадры?
Бытует такое мнение, что если ты держишь руку на пульсе — то значит не доверяешь. И типа, какого черта кого-то нанимать, если потом не доверять.
В общем, как говорится в пословице «доверяй, но проверяй». Во первых, доверие должно вырастать из фактов, а не из желания верить. Только, если человек, сделал X раз все четко, качественно и выверено, то это значит, что в X+1 раз ему можно таки доверять. Все дипломы, регалии, хорошие отзывы и т.п. — вторичный признак и должны быть подтверждены фактами.
Тем ни менее, даже доверяя, нельзя пропускать какие-то пункты из нашего списка. Задача все еще должна быть четко сформулирована, так как без формулировки даже самый лучший исполнитель не сможет ее выполнить. В конце нужно настолько же тщательно все проверять, для оценки окончания задачи. Что можно серьезно уменьшить — это промежуточный контроль в случае долгого и успешного сотрудничества.
г) Делегирование больших задач
В какой-то момент от прямого делегирования а-ля «Вася — пойди выкопай яму», приходится переходить к «Петя — твоя задача организовать пяти Вась, чтобы они засадили двор яблонями».
Тут есть несколько подводных камней. Разбивать на супер мелкие подзадачи самому (план где сажать деревья, тип яблонь, какую подкормку деревьям сыпать) — слишком долго. Отдать все это на откуп Пете, а потом обнаружить, что все сделано абсолютно не так, как вы бы сделали — тоже как-то не хочется.
По этому поводу несколько советов
— Во первых, из очень хороших исполнителей Васей, не всегда выходят хорошие организаторы Пети. Поэтому Петю нужно искать среди тех, кто и как исполнитель неплох, но и имеет задатки организатора.
— Во вторых, нельзя сразу на них бросать большую и супер критичную задачу. Нужно, чтобы у них была возможность привыкнуть руководить, а вы увидели, что он он руководит правильно
— Третье, нужно показать как вы сами руководите и объяснять для чего и что делается (чтобы дать нужный инструментарий, а не заставлять человека самому изобретать велосипед).
— Четвертое, это то, что при делегирование больших задач, нужно проходить те же самые пункты, как при обычном делегировании. Так как задача большая — то важно поставить цели, объяснить, как эта задача ложится в больший план (чтобы человек мог сам «доточить» задачу), разбить на этапы. Дальше, поэтапно контролировать и в конце принять задачу.
Ключевым является то, что до появления доверия, нужно просматривать план составленным подчиненным и вместе его корректировать. Просмотр и коррекция плана составляет обычно гораздо меньше чем его составление.
Фух… Ну вот вроде и все, что хотел сказать. Как писал в начале. Вышла длинная колбаса.
С удовольствием отвечу на какие-то конкретные вопросы и приму замечания.
И действительно, навалял шо-то ты кучу… букав 🙂
В целом согласен по всем пунктам. Не знаю, насколько всеобъемлющей получилась даже такая колбаса, так как тема действительно обширная, но то, что есть, вызывает желание активно поддакивать. Позволю себе несколько мелких комментариев:
Вообще, положа руку на область желудка, программирование в IT бизнесе имеет примерно такую же важность, как вождение грузовика в доставочном бизнесе
Ооооо!!! Я уже запасся попкорном, пивом и стерео очками в предвкушении того, как тебя щас будут рвать программисты :))) Может, правда, и мне через очки достанется, потому что я тоже считаю, что такова суровая правда жизни. Когда аутсорсишь из Украины, кажется, что заказчики часто просто полные кретины. А поработав в продуктовой компании на разных уровнях понимаешь, что вид из танка/кабины грузовика просто не дает возможности видеть панораму событий и адекватно реагировать. Перефразируя твою же мысль, генерал может быть нереально крутым танкистом, но если он будет ездить в своем танке и мочить всех подряд, войну его армия все равно очень быстро просрет.
Третье, нужно показать как вы сами руководите и объяснять для чего и что делается (чтобы дать нужный инструментарий, а не заставлять человека самому изобретать велосипед).
Я бы это выделил жирным шрифтом. Это суперважный пункт, который очень часто упускается из вида. Мне кажется, причин тут может быть две (как минимум):
а) Руководитель владеет этим инструментарием, набил себе уже кучу шишек, и в итоге данные действия стали практически сами собой разумеющимися. Нужно заставить себя понять и периодически напоминать себе о том, что не для всех это столь же очевидно. Тем более, что обычно любые действия так или иначе подстраиваются под свой характер. Можно называть это почерком, закидонами, улучшениями и т.д. Суть остается в том, что любой процесс адаптируется под человека, т.е. под руководителя в данном случае. Напоминаю,мы говорим об IT компаниях, а не об армии, где таки все по уставу, к которому адаптируют как раз людей. В итоге это говорит о том, что процесс становится еще более неочевидным для других людей, и их нужно научить. Вот мы и подобрались ко второй причине
б) Очень многие руководители из exUSSR, особенно новоявленные, отказываются соглашаться с необходимостью инвестировать в обучение людей. Логика простая как двэри: я ему плачу больше, чем остальным, пусть и отрабатывает и доказывает. Я ему плачу больше уже сейчас, чего вдруг я должен еще ждать, пока он научится когда-то там позже? В общем это примерно из той же области, что если бизнес не окупается через полгода, а потом не приносит 50% прибыли в год, значит это херовый бизнес. Можно конечно нанять мегамонстра, который все это знает и проходил. Но стоит признаться в парочке вещей:
1. мегамонстр потратит какое-то время, и это явно будет не одна неделя, на то, чтобы разобраться с текущей ситуацией.
2. мегамонстр начнет перестраивать процесс под себя и дальше у вас появится обратная проблема — заставить мегамонстра делать то, что хотите вы, а не то, что хочет он.
3. в такой уж совсем мелкий стартап мегамонстра еще попробуй заманить. Да даже не мегамонстра, а просто сильного менеджера с каким-то более или менее неплохим опытом. Чего ради он пойдет в гараж?
Так что остается воспитывать и продвигать свои кадры. Но как ты верно сказал, если Вася рвет и мечет программистские задачи, это еще далеко не факт, что он будет так же лихо организовывать людей и решать проблемы. Так что я бы добавил отдельным пунктом к твоему списку готовность инвестировать в развитие людей прямыми или скрытыми путями даже на начальном этапе стартапа. Когда денег на такую роскошь как бы и нет.
PS Первый нах 🙂
Увы, попкорн не пригодится 😉 Для этого нужно было отдельной статьей это писать, а не абзацев в центре длиннющей статьи.
По поводу а) согласен. Многие привыкают к тому, что они знают и плохо умеют из себя «вынять» и поделиться с кем-то знаниями.
По поводу б). Я бы сказал, тут проблема еще в том, что рынок молодой и бурлящий. Поэтому люди зачастую переходят с работы на работу достаточно часто. В такой ситуации инвестирование не выгодно.
Насчет мегамонтсров…. Сложное это дело. Единственный метод узнать монстр он или нет — это таки увидеть его в деле. А чаще всего мегамонстрами называют тех, кто просто умело рекламируют себя и не обязательно так уж хороши.
Читай ниже, слегка попкорна таки удастся поесть 🙂
О, это уже веселее. А он тебя щас с правой. А ты подныривай, и апперкотом его попробуй. Ну и т.д., а я пока за пивом в холодильник схожу
Очень актуальную для меня темку подняли.
Тяжко у меня процесс делегирования-проверки исполнения проходит, много времени занимает. Постоянная нехватка времени гнетёт, блин…
«плохой контроль в ключевых точках» — это про меня 🙂 Пойду проконтролирую 🙂
> Вообще, положа руку на область желудка, программирование в IT бизнесе имеет примерно такую же важность, как вождение грузовика в доставочном бизнесе
Есть разные IT-бизнесы — например, сервисный и продуктовый, я уж не говорю о специфичных случаях. Лучше всего см. здесь — http://russian.joelonsoftware.com/Articles/FiveWorlds.html, Джоэль Спольски, «Пять миров ПО».
В разных мирах роль программиста (на самом деле не программиста, а архитектора, потому что я тоже не видел, чтобы директор сам писал весь код постоянно) разная. В некоторых случаях архитектура является критичным конкурентным преимуществом — большая эффективность, масштабируемость, меньшие затраты. И пускать её на самотек никак нельзя — контролировать нужно, поскольку 100 плохих программистов все равно не сделают такую же программу, как 1 талантливый.
Но это, повторюсь, частности, и к сервисному IT-программированию, которым занимаются 90% фирм, не имеет никакого отношения — там верна именно ваша фраза.
Прочел статью Джоэля, как обычно она хороша.
Тем не менее, везде программисти играют таки роль водителя грузовика. Только к нем требования разные. Где-то нужно что-бы он вел с напарником, мягко и аккуратно, записывая каждую колдобину на которую он наскочил. Где-то нужно доставить в кратчайшие сроки.
> В некоторых случаях архитектура является критичным конкурентным преимуществом – >большая эффективность, масштабируемость, меньшие затраты. И пускать её на самотек никак >нельзя – контролировать нужно, поскольку 100 плохих программистов все равно не сделают >такую же программу, как 1 талантливый.
ok. Есть еще те, кто водят формулу 1, там 100 плохих водителей не заменят одного хорошего.
Только это не играет никакой роли, важно то, что Феррари хочет себя отрекламировать и вкладывается в формулу 1, а не то, что водитель очень хорошо умеет ездить.
Суммируя. В бизнесе самое главное — это бабки. Так уж сложилось, что бабки в современном мире наиболее хорошо контролируются sales и marketing’ом. Остальные отделы являются всего лишь необходимым злом с которым первые мирятся.
А чем бы эти задачи автоматизировать? На начальных этапах удобнее карандашом на бумаге. Но потом невозможно перейти на всякие аутлуки, так как они думают не в тех же схемах, что и я. И подстраиваться под мнение софта — мазохизм.
Вот, собственно, что порекомендуете из софта по управлению задачами? Не планированию их, как в MS Project, не ведению списка как в MS Outlook, не пинанию тикетов как в трекерах всяких. А именно задачи в своей совокупной связности, зависимости, и т.п.
Посмотри на http://www.pastukhov.com/knowledge-base.php — под это и задумывался
Тот же OneNote, только сбоку. Из-за обособленности продукт непонятно его будущее. Мои задачи, судя по картинке и описанию, оно не решает; потому как их не решает и OneNote.
Короче, надо делать самостоятельное исследование, искать правильные ключевые слова…
Просто скачай и посмотри — продукт бесплатный.
Основная суть продукта — в свободной линковке документов (задач, людей и всего, чего душа пожелает). Ctrl+C Ctrl+V — это все, что требуется для линковки.
Я сам в нем такое же планирование и отслеживание задач делаю. Упор больше на GTD, но это сути не меняет.
Мое мнение следующее.
а) Карандаш и бумага — must have.
Причины тут две
— они доступны гораздо быстрее, чем софтверные средства
— они более гибки к изменениям (можно вести так как это кажется правильным, а не так как хочет софт).
Впрочем, я пользуюсь обычным ежедневником. Если мне надо что-то сделать, я просто записываю дело на это дату. Тоже самое, если мне нужно что-то проверить.
б) Достаточно часто бывают задачи, которые например идут в несколько фаз — исследовать,
составить план и сделать. И вот такое уже не так удобно вести в блокноте. Для мелких контор все еще можно продолжать вести на бумаге, когда компания становится больше, мне ближе всего именно системы ticket’ов. Они отражают лучше всего суть. Есть задача «X», она может пройти через N состояний.
Честно говоря, вводить все связи, зависимости, даже мне (при том, что я педант и любитель аккуратности) не приходит в голову. Собственно говоря, я отделяю чаще всего проектные задачи (которые имеют свойство быть сильносвязанные), от обычных управленчиских задач.
Проектные задачи храню в SCRUM tool’е, так как связи в них меняются, а скорее важен порядок их выполнения.
Да, еще насчет софтверного подхода. Собственно говоря, меня напрягают «накладные расходы» по времени. Нельзя сказать, что они очень большие, но мне проще за 3 секунды открыть и вписать дело, чем ждать пока выйдет из sleep notebook, запускать программу, перейти на нужный view и ввести текст.
Я писал с пару недель статью о девайсе о котором я мечтаю. Одна из его фич как раз ведение дел.
Ну тут врядли кто будем спорить ИМХО.
Я практикую следующую практику, когда я перестаю удерживать задачи на текущий день в голове (что впрочем, считаю признаком того что я до этого делал что-то не так)
Я записываю все задачи на листке бумаги, причем очень стараюсь делать это не торопливо — т.е. читай красиво, аккуратно и лаконично(чтобы пояснить насколько это я считаю важным для себя — я даже чтобы соответсвовать монтбланк себе купил)
После выполнения любой задачи, я записываю все задачи на чистый листок, причем стараюсь не тупо переписывать, а формулировать заного.
Время затрачиваемое на переписывание и переформулировку позволяет оценить важность, необходимость и коректность формулировки задачи еще раз.
Для меня это работа на порядок лучше, чем просто ревизия уже написанных задачь. Может и кому пригодится.
Вот тут хочется пообсуждать. СОВСЕМ без владельца безуслово. С участвием владельца в десяток часов в месяц — думаю к этому имеет смысл стремится.
В классическом шареваре у меня (я больше по мобильным девайсам) опыт не большой, и даже скажем не удачный. Но этот неудачный опыт приносит мне 150-200 долларов ежемесячно. Затраты — 17 ответов на письма за 2009 год. Из них 8 просьб напомнить серийный номер, 4 просьбы refund, и 5 писем переписка о проблеме. На первые 12 суммаро порядка часа времени, на последние 5 — поряка 2 часов.
2008 год писем был порядка 60-ти. 2010 вероятно будет так же….далее уже нет скорее. Затраты на разработку окупились еще в 2007-ом. Но это скорее fail чем, win.
Но в этом плане меня большее вдохновляет другой пример.
Мне известно о бизнесе одного человека. Он в свое время разработал схему определенного устройства которое конструктивной частью дома/квартиры. На данное устройство есть небольшой устойчивый спрос в определенных регионах обусловленный географическими особенностями.
В текущий момент его бизнес выглядт следующим образом.
1. Компании которые занимаются строительством/ремонтом жилья в этих регионах включают данный прибор как опцию при стоительстве и делают мало-оптовые (от 10 штук в месяц) заказы.
2. Телефонный суппорт в Индии который отслеживает всю рекламу в данных регионах и отслеживает новые компании из списка 1 и информирует (звонками как правило) их предлагая включить данный прибор в опции, рассказывая о премуществах прибора.
3. Телефонный супорт опять же в Индии который работает с конечными потребителями — отвечая на простые вопросы о использовании, либо перенаправляя их в компании из пункта 1, которые при контракте обязуются делать X часов бесплатного сопровождения.
4. Компания-склад которая занимаются хранением определенного количества устройств, мелко-оптовой рассылкой компаниям из пункта 1 и крупно-оптовой ( несколько сотен штук) заказов от фабрики производителя.
5. Фабрики в Китаее (в одни момент времени миниум 2 штуки одноверменно) которые по запросу компании 4 производят и высылают крупные парти устройств используя документацию которая у них есть (сборка ручная).
6. Личный секретарь опять же в Индии, который обзванивает все эти компании и получает от них отчеты и все это формирует в единый глобальный отчет.
7. Финансовая компания в США которая занимается финансовыми и налоговыми вопросами, аккумулированием денег и выплатами всем из пунктов 2-6
Его работа фактически заключается в анализе этого отчета и принятии решения эффективности и замене компаний из пункта 2-6.
Плюс определенное количество часов в месяц он тратит на проработку новой иде устройства, ища места где есть потобные потребности. Совмещая это с путеществиями по миру.
Он очень скурпулезно следит за тем сколько времени он трати и у него получается порядка 20 часов в месяц на поддержание работоспособности описанного выше. Причем он пытается не размазывать это время, а выделять его кускам не более чем 5 часов за раз.
Единственный фосмажор за 4 года существования этой схемы — проблемы с фабриками, он решил одной недельной поездкой в Китай.
Общий доход у него не велик, в за 4 года в среднем 200к долларов в год.
Вот подобные схемы очень интересны. Извиняюсь, что так много слов 🙂
Насчет записи дел на листочке, сам практиковал, до тех пор пока количество дел не перевалило за 10-15 штук. Записываю я правда не только деловые дела (а-ля поход к дантисту 15 числа).
В среднем у меня где-то штук 30-40 дел размазанных на следующий месяц, которые записаны в ежедневнике. На листке уже не удобно, в голове уже нереально.
По поводу вашего опыта в shareware. Если вы живете на территории exUSSR и при этом не в Москве и Питере, то как по мне результат вполне не плох. Добавить 2-3 программы, и это вполне достигнет уровня дохода, на который можно жить. Если вы живете в США, то действительно радости от 200 в месяц не много.
Насчет того, что вы описали об одном человеке. Завидую ему белой завистью 😉 Думаюа в чистом IT (услуги, софтверные продукты и т.п.) очень тяжело добиться такого эффекта. Во первых в отличии от производства гораздо больше чего может пойти не так, во вторых происходит гораздо быстрее устаревание продукта.
Я знаю только одного человека в штатах живущего с нескольких продуктов. Насколько я знаю, он не перегружен, но явно тратит больше 20 часов в месяц.
Кстати, такой вопрос. Этот один человек, насколько долго занимается этим бизнесом и что у него с стартовым капиталом было?
Я переключаюсь на бумажку, когда у меня становится более 5 активных проектов. Там так же не только деловые вещи — походы к дантисту и прочее, я тоже вписываю. Но только когда я еще не знаю когда я точно пойду, просто чтобы сходить как будет свободное время.
Задачи типа похода к дантисту 15 числа я стараюсь делать самоорганизуемыми — т.е. дантист мне должен позвонить за день и напомнить, и потом за час позвонить.
Или элементрано напоминалку в телефон — у меня на базе андроида поэтому достаточно добавить в гугл календарь.
В бумажке у меня обычно порядка 8 пунктов, 2-3 из которых имеют по 4-8 подпунктов. Как раз лист А4.
Если у меня жопа и количетсво ожилающих дел перевалило за 30, то я их вбиваю в MyLifeOrganized — и текущие на неделю выписываю.
Основной смысл бумажке не в сколько в контроле, хотя это удобно видеть ее на столе, а сколько в том, что если ты в пятый раз раз переписываешь задачу ты можешь наконец понять что ее делать то и не нужно, или нужно не так как ты планировал. Или наоборот нужно сделать asap. Плюс есть еще класс задачь которые во первых противные, а во вторых не актуальные — т.е. их можно сделать сейчас, а можно через пол-года. Обычно они и делаются через пол-года, накапливаясь. А тут тебе ее раз вписать — и после двадцатого переписывания, уже плюнешь и сделаешь.
Настраивал эту схему он год примерно. Работает она четыре года. Стартового капитала небыло фактически. Ну вернее там отпускные+премия с основной работы с которой он уволился. Первый десяток девайсов собрал сам, фирмы стоительные обзванивал сам, клиентам отвечал сам, ремонтировал ходил сам. Потом нанял местную контору на отслеживане прессы и отзвон в стоительные компании, заодно написал FAQ — типа что говорить клиентам и компаниям. Потом начал заказывать мелко оптово приборы опять же в местной компании. Потом после того как его и о его приборе узнали переложил первичный суппорт конечных клиентов на плечи строительных компаний и той же конторы что их остлеживала. Потом вытащил производство в Китай, получал заказы сам и рассылал компаниям сам. Потом суппорт в индию, пользуясь статистикой и данными с от местной конторы. Ну потом все остальное.
Нужно правда упомянуть что у него маржа высокая изначально. С каждого девайса когда он делал сам он имел 300% прибыли, а когда всю схему организовал имеет 100%.
Восторгаюсь этим человеком. Без начального капитала, девайсы с 300% прибылью, за год все настроил.
Насчет бумажного ведения дел. Кстати, тоже за это люблю бумагу, что переписав дело раза 3-4 уже думаешь, а не выкинуть ли его нафиг.
Возникла мысль. оценивая прибыльность дела, т.е. эффективность продаж, ты рассчитываешь на какие-то ключевые особенности продукта или услуги за которые кастомеры и будут платить деньги. Сходу приходит в голову 1) иновационность (продать то, чего еще никто не продает) 2) больше качества за те же деньги (продать то, что продают многие, но при этом еще втиснуть в ту же цену что-то дополнительное: мелкую фичу, улучшеное юзабилити, более красивый дизайн) 3) узконаправленная специализация, заточенность под определенную группу кастомеров. (фактически снижение стоимости продукта, по сравнению с продуктом конкурентов, путем обрезания ненужных узконаправленной группе кастомеров фич).
И вот при делегировании задач наемному работнику в варианте 1) ты рискуешь тем, что идею твою узнает кто-то со стороны, переработает и выпустит раньше чем ты. (про патенты и прочие авторские права я бы не стал в нашей стране вспоминать. тут такой правовой бардак, что страшно жить :)) В варианте 2) получается что продукт выпускаешь уже не ты, а ты только управляешь, т.е. создание продукта — это результат работы многих людей и эти многие люди уже не факт что смогут выпустить что-то лучше, чем у конкурентов. Вариант два возможен, когда у тебя уже точно есть целая команда наемных людей с которыми ты давно работаешь и уверен как в самом себе. Остается только вариант 3) — выпускать дешевый продукт или оказывать дешевую услугу для узскоспециализированной группы кастомеров. Но тут конечно о масштабном бизнесе и не стоит думать. Это будет маленький бизнес всегда, его невозможно будет расширить. Но на нем можно воспитать команду подчиненных, чтобы потом когда-то бросить этот маленький бизнес и всей своей командой рискнуть с вариантом 2).
Пройдемся по пунктам
1) Ты рискуешь тем, что идею твою узнает кто-то со стороны, переработает и выпустит раньше чем ты.
Честно говоря за 10 лет не сталкивался с таким случаем. Идеи вообще стоят по 10 копеек за пучок в базарный день. Очень важно таки исполнение.
Поэтому идею нужно не просто украсть, ее надо исполнить еще и лучше.
2) учается что продукт выпускаешь уже не ты, а ты только управляешь, т.е. создание продукта – это результат работы многих людей и эти многие люди уже не факт что смогут выпустить что-то лучше
Это только значит то, что в управление надо включать слежение за качеством. Особенно, если качество является критической величиной для продажи.
3) выпускать дешевый продукт или оказывать дешевую услугу для узскоспециализированной группы кастомеров
узкая специализация и дешевая цена — это как раз слова антонимы. Чаще всего при узкой специализации — цена высокая.
А вот плохое качество и дешевая цена — таки синонимы, но тут уж читай пункт 2). 🙂
Вообще, положа руку на область желудка, программирование в IT бизнесе имеет примерно такую же важность, как вождение грузовика в доставочном бизнесе
Не очень понимаю почему мало кто замечает бредовость данной аналогии. А некоторые даже намеренно соглашаются. Фразочка ведь явно просто провокационная и автор поста сам же противоречит ей чуть ниже в комментах: Честно говоря за 10 лет не сталкивался с таким случаем. Идеи вообще стоят по 10 копеек за пучок в базарный день. Очень важно таки исполнение.
Вы там как-то определитесь — важно исполнение ( программирование ) или не важно :).
Если уж про аналогии, то по-моему ближе к реальному положению вещей было бы так — программирование имет такую же важность, как навыки пилотирования стелсом в современной военной кампании.
Казалось бы и то и то — «вождение», но как говорится почувствуйте разницу…
Или ваше программирование как у малообученных индусов, которые путают красный свет с зелёным и ездят не зная правил на колымагах 50-х годов, или как у звена истребителей оснащённых по последнему слову техники и управляемых профессионалами.
Жующим попкорн — приветы, кушайте не подавИтесь :).
По пунктам:
Потому что это правда.
а) Исполнение включает в себя не только программирование, но и позиционирование, продажи, работу с партнерами, product management и т.п.
б) Как я и говорил, без программистов никуда (как и без водителей грузовиков). Но обязательность, не значить первостепенность.
в) Любая провокация находится не в тексте автора, а в голове читателя 🙂
Надежды юношей (возможно уже не юношей) питают. 😉
Естественно сравнение с водителям грузовиков очень поверхностное.
Можно выделить три десятка критериев и начать сравнивать по ним и естественно окажется, что все сильно отличается. Если так сделать, то вообще очень тяжело провести любые параллели.
>Подход “сначала продадим, а потом сделаем” может кому-то кажется инновационным и >перспективным, но думаю, это просто некое веяние типа доткомов или вебдванолей и >эта мода похоже начинает утихать.
Это модель не начинает утихать, а наоборот все разрастается.
У человека (американца) есть идея, он вкидывает в нее $10k делает прототип (левый и корявый), идет к инвесторам и __продает__ им прототип идею, те вкидывают в это $1M, нанимают водителей (ой… извините программистов), которые напедалевают код (не всегда самый лучший и самый качественный), sales и marketing __продают__это в несколько десятков корпораций, с этими результатами идут к более крупным инвесторам и __продают__ эту идею им, те вливают $10M, нанимают еще людей. Это все еще больше разрастается и продают еще большим количеством компаний. В концу концов все это продают Amazon, Google, Microsoft или еще кому-то, или выходят в IPO и т.п.
В этот момент кто-то, кто вкладывает в технарей, давно выкинут с рынка, так как конкурировать с фирмой в которой 100 человек в engineering’е и 100 в sales нереально.
А технологическое преимущество. Когда фирма будет нанимать очередных программистов, то скажем X% из них окажутся хорошими и будут тянуть техническую часть на себе вперед.
А вот без продажного преимущества, фирма просто не сводит концы с концами и все… нету фирмы.
А по главной теме поста — спасибо.
Действительно хорошая информация про делегирование.
Отличная тема, жизненная. Проблемы контроля исполнения меня интересует меньше, процесс более или менее налажен, как-то проиходит все само. За программистскими задачами слежит баг-трекалка со статусами и ответственными за каждую ступень. Для всего что в этот формат не попадает, скажем работа, отдаваемая на сторону, решается подбором ответственных или проверенных сотрудников, фрилансеров или компаний. Если сроки не волнуют, можно просто отдать на исполнение и дождаться когда будет готово.
Лично для меня самое интересное это принятие решения «сам» (или силами компании) или отдать на сторону. Тут бывает, что в зависимости от ситуации одно и то же решение принимается по-другому. Играет роль и срочность и важность и наличие денег/времени.
Бывают интересные ситуации, когда ни самим ни на сторону полностью отдать нельзя. Скажем была задача написать и разослать пресс-релиз после выхода очередной версии. У компании, которая рассылает пресс-релизы было спецпредложение — пишут релиз бесплатно. После писателя пришлось пройтись, кое-что подправить, чтобы стало технически грамотно. Потом отдали нативу на пруфридинг. Потом опять подправили с точки зрения технической грамотности и сделали акцент на нужные фичи. Потом отдали обратно на рассылку. Итого пять итераций.
Ну, для тебя эти темы уже в прошлом 😉
Все таки — это скорее пишется, для людей, которые впервые «отрывают» от себя любимую игрушку и должны отдать ее в руки незнакомого дядечки, которого еще и контролировать надо.
А вот насчет задач, который полностью никто толком не может сделать… Это действительно — достаточно неприятно. Вроде мельчайшая задача растягивается на много итераций.
Наконец, я фактически добил первую версию своего продуктика (продуктом пока это назвать нельзя). Документацию написал сам, сейчас отдаю на proofread, потом подправить, а потом отдать привести ее божеский вид с точки зрения того, как она выглядит (дизайн).
Но тут вряд-ли, что-то можно придумать. Либо находить компанию, которая умеет все и возьмет много-много денег за это умение, либо становится большими и толстыми и держать личного маркетолога, редактора и т.п.
Всё не осилила дочитать, но вижу дисскуссия тут горячая.
«Честно говоря за 10 лет не сталкивался с таким случаем. Идеи вообще стоят по 10 копеек за пучок в базарный день. Очень важно таки исполнение.»
Вот с этим я не совсем согласна, мне кажется придумать трудней, чем исполнить:)