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

Боб Волш в прошлом программист с огромным опытом, а теперь автор нескольких книг и консультант в области стартапостроения.  Его предыдущие книги касаются двух направлений – социальных медиа и идее micro ISV – то есть, «компаний», состоящих из одного человека, программиста. Не знаю, как насчет социальных медиа, но идея micro ISV для Боба явно выстрадана и проверена личным опытом. И да – нет, Боб не является автором нескольких удачных стартапов, хотя опыт у него крайне богат, но это тот прекрасный пример, когда даже очень умный и талантливый человек вовсе не обязательно добивается мгновенного успеха в стартапе. Впрочем, он продолжает пытаться – посмотрите на его проект startuptodo.com (говорят, в золотую лихорадку больше всех заработали продавцы лопат).

Уверен, многие программисты так или иначе задумывались об идее micro ISV (только, конечно, не называли ее так). Идея довольно простая: что же это я пишу-пишу, а миллионы на моем коде зарабатывает кто-то другой? Или, например, так: что за дурацкие задания мне дают, кто так пишет софт! Я сам гораздо лучше понимаю, как его писать, не вырваться ли мне из-под гнета «дяди», который ничего не понимает в толковом софте?  Боб Волш прошел этот путь, набил свои шишки, натер свои мозоли, получил свои уроки, и пообщался с целой кучей умных людей на эту тему. И он написал об этом книгу!

То, чего, как правило, не видят программисты, это огромный мир бизнеса, в котором не так уж важно, какой именно продукт ты делаешь. Очень быстро оказывается, что блестящий код и смелые решения – это только часть, и далеко не самая большая. Что продажи и маркетинг, пожалуй, важнее интерфейса и отсутствия багов. Что для победы в конкурсе красоты мало быть красивым – нужно еще и принять участие в конкурсе красоты. Как же быть? Один из вариантов – найти себе партнера, который сможет выполнить эти функции, и тогда, вдвоем, или втроем, вы сможете быть сильной командой, имеющей таланты по всем важным для молодой компании направлениям. Второй вариант, micro ISV – стать специалистом и в остальных, недостающих областях. Почему бы одному человеку не быть и программистом, и маркетологом, и продавцом, и многими другими виртуальными работниками в своей компании-одного-человека? Конечно же, Боб Волш не знает, что такое ведение бухгалтерии и налогового учета в Украине, поэтому считает, что все это возможно совместить в одном талантливом человеке.

Что вы найдете в этой книге? Ни слова о программировании, вы сами решите какой продукт и как создавать. Гораздо важнее понимать ценность вашего продукта, а это не так уж очевидно. Если вы делаете стартап, micro ISV, назовите как вам удобно – вы начинаете игру в деньги. Их надо заработать, и тот, кто делает это лучше, вовсе не обязательно лучше программирует. Он лучше понимает, кто их заплатит и почему. Он лучше знает, как найти потребность и удовлетворить ее. Как говорить со своими клиентами, и, хотя бы, дать им знать, что продукт существует.  Как найти деньги в тот момент, когда они нужны. Как быть очень-очень продуктивным, ведь успех дается только упорным и кропотливым трудом. Почему инвесторы делают инвестиции, и кому они их не дадут.

В книге не только размышления Боба на эти темы, в ней также множество интервью с теми, кто преуспел в этом. Не все имена известны в наших широтах, но Гай Кавасаки и Джоел Спольски одобряют и дают интервью этому человеку. Это не то, чтобы гарантия качества, но все-таки – авторитеты, что называется, тянут мазу. Отдельно я хочу упомянуть выдающуюся подборку эпиграфов к каждой главе – это очень емкие и интересные цитаты.

Я считаю, что каждый программист, который больше трех раз думал о том, чтобы сделать что-нибудь эдакое, стартапчик там, или еще какой замут, мог бы потратить двадцать баксов и пару дней, чтобы прочитать эту книгу, стать умнее, и, возможно, никогда больше не думать об этом. Или продолжать думать,  но уже гораздо более трезво. Это гораздо дешевле и быстрее, чем набивать все те же шишки самостоятельно. Неспроста самая первая фраза на обложке гласит: from developer to founder.  И, конечно, не стоит забывать, что самые смелые и громкие проекты сделаны скорее вопреки, чем благодаря книгам, учебникам и наставлениям. Для чего их, разумеется, надо прочитать.

Знание – сила!

Алексей Колупаев,

kolupaev.com

Почему управление — это в первую очередь измерение? Есть масса различных формальных и не очень определений понятия “управление”, все они по сути похожи: управление — это действия, направленные на объект, для достижения цели. То есть, управление базируется на трех предпосылках: действия, объект, цель. Если чего-то из них нет — нет управления. Как это может быть? Давайте разберемся. Как может не быть действий? Это ситуация, когда вы ничего не можете поделать с объектом. Например, мы все знаем, что Земля вращается вокруг Солнца, но повлиять на эту ситуацию у нас нет никакой возможности. Такое “управление” можно назвать наблюдением. Как может не быть объекта? Например, вы можете прослушать курс лекций по управлению космическим кораблем, но если вас к нему не допустят — это останется теорией. Такое “управление” можно назвать теоретической подготовкой. Как может не быть цели? Это, например, когда вам на улице дали пистолет, объяснили с какой стороны он стреляет и куда жать, и на этом попрощались. Такое “управление” можно назвать… наверное, глупостью.

Разумеется, я хочу поговорить о цели. Цель — не менее важная абстракция в жизни человека, плотно связанная с Мотивацией, и, соответственно, являющаяся одной из основополагающих концепций человеческой деятельности вообще. Что интересно, еще с 1954 года существует целое направление менеджмента, посвященного именно управлению целями – Management by Objectives. В нем вводится понятие цели, точнее даже не понятие, а обязательные свойства цели, без которых цель — не цель. Вот эти свойства:

A simple acronym used to set objectives is called SMART objectives. SMART stands for:

1. Specific — Objectives should specify what they want to achieve.
2. Measurable — You should be able to measure whether you are meeting the objectives or not.
3. Achievable — Are the objectives you set, achievable and attainable?
4. Realistic — Can you realistically achieve the objectives with the resources you have?
5. Time — When do you want to achieve the set objectives?

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

Что такое измеримая цель? Очевидно, это означает, что существует некий критерий ее достижения. То есть конкретный способ однозначно ответить на вопрос “достигнута ли цель?”. Менее очевидно, но также понятно, что существует некоторая мера, позволяющая оценить изменения, спровоцированные теми самыми действиями в отношении того самого объекта. Оценить с одной простой точки зрения — они приближают к цели или нет? Были ли действия правильными? Как мы можем знать, сработали ли те или иные действия, и как именно?

Проблемы возникают как с первым (критерием достижения цели) так и со вторым (мера близости к цели). И в принципе, с точки зрения “business value” и то и другое — критично. В первом случае — невозможно определить конец проекта. При этом, обратите внимание, цель как таковая есть, сформулирована и многими может восприниматься вполне нормально. Например — “повысить прибыльность компании” (как понять, что проект выполнен? Является ли увеличение прибыли на один доллар сигналом к прекрещанию проекта?) или “увеличить посещаемость ресурса”, “повысить уровень грамотности населения”, “построить коммунизм”.

Во втором случае, когда нет меры близости цели, невозможно оценить прогресс, и, следовательно, вероятность успешного завершения проекта, проблемы с управлением рисками, с обратной связью. Мы предприняли действие — произошло изменение, но наша цель такова, что мы не можем сказать, хорошее это было изменение или нет. Имели ли эти действия смысл? Это происходит, когда команда не слишком хорошо понимает, что  влияет на достижение цели. Приведу такой пример: допустим, проект — это игра в шахматы. Цель — поставить противнику мат (хорошая цель, есть конкретные критерии ситуации “мат”). Но вы не умеете играть в шахматы, только знаете, как ходят фигуры. Вы можете предпринимать какие-то ходы, но в целом, крайне сложно сказать, был ли каждый конкретный ход успешным, то есть — приблизил ли он мат противника. 

Казалось бы, все достаточно понятно и просто, в чем же проблема? Это же, в общем, вполне понятные вещи? Давайте посмотрим, как эти идеи воплощаются в реальных проектах.

Итак, чем же специфичен большой реальный проект? Он интересен тем, что его цель, как правило, достаточно глобальна и сложна в достижении. Во всяком случае, насколько сложна, что одному человеку с этим никак не справиться. Поэтому людей в таком проекте работает много. В первую очередь — из-за компетенции: сложный проект требует сильных сторон команды в большом количестве разных отношений. Технологии, управление, продажи, закупки, маркетинг, поддержка, клиентский сервис, дистрибьюция, логистика — это реальность современных проектов.  Могут ли все эти направления “закрываться” одним человеком? Вряд ли. Вторая проблема — количество рук. Даже если предположить, что в одном конкретном проекте нужно не так много навыков, как правило время жизни проекта в сочетании с объемом необходимых работ говорят о том, что в одиночку его сделать невозможно. Нужно больше рук. Нужно больше умов. Нужно двигаться быстрее.

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

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

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

Что же произошло? А произошло вот что: операторы колл-центра, видя, что позвонивший клиент разговаривает долго, задает много вопросов, и вообще тянет беседу, попросту бросали трубку. Нет смысла долго говорить с человеком, если важно обработать максимальное количество звонков в час.

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

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

You are what you measure

Вы — это то, что вы меряете. Ваша работа — это то, что вы меряете. Вы делаете то, что вы меряете. 

Из этого есть три важных следствия:

• Если вы думаете, что делаете что-то, но не меряете это что-то — вы на самом деле не делаете этого.
• Если измерять что-то, делать это упорно, открыто и настойчиво — вы начинаете делать это.
• Если вы меряете какую-то глупость — вы и делаете какую-то глупость. 

Отсюда вывод — чтобы начать что-то делать, нужно начать это мерить. Иначе это стрельба в темноте от пояса. Может, конечно, что-то и получится, в конце концов, есть же такая вещь, как спасительная интуиция. Но я не готов поставить на нее.

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

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

1. Вы знаете, какая цель у проекта, над которым вы работаете? Можете ее сформулировать?
2. Доступны ли вам результаты измерений достижения целей проекта? Знаете ли вы их?
3. Вы знаете, какая модель достижения цели проекта? Ваше место в ней?
4. Вы знаете, какая цель стоит перед вашим подразделением? Доступны ли вам результаты измерений по ней?
5. Вы знаете, какая цель стоит перед вами?
6. Как вы измеряете свои успехи в достижении вашей цели?
7. Есть ли у вас отчетливое понимание, какую бизнес-ценность добавляет ваша цель вашему проекту?

Ну, а если вы менеджер проекта, скажите — как ответят на эти вопросы ваши подчиненные? А как ответит ваш начальник, если у него спросят, как ответите на эти вопросы вы?

Привет всем читателям ДОУ, доброе утро и — помогите нам, пожалуйста.

Я уже не раз рассказывал о том, что мы делаем стартап, и, как многие помнят, искали единомышленников среди сообщества. Могу наконец с чистой совестью сказать, что все было не зря, что мы наши тех самых людей (но поиски не остананавливаем!), и, наконец-то, дожили до бета-версии. Ее можно увидеть по адресу maanimo.com. Она еще нежная и беззащитная, и в ней есть недостатки, но ведь на то она и бета, не так ли?

Попытаюсь описать в двух словах цель, которую мы преследовали:

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

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

Мы приглашем вас познакомиться с нашим детищем, и рассказать о своих впечатлениях, чтобы мы смогли исправить свои ошибки к финальной версии, сделав сайт удобнее и полезнее. Автору самого справедливого из гневных комментариев мы подарим легендарную книгу «Founders at work» Джессики Ливингстон, под влиянием которой мы решили делать этот стартап.

Всем заранее большое спасибо, и — судите строго и справедливо!

P.S. RSS и поиск сейчас отключены намерено — появится на следующей неделе.

P.P.S. Тотальная AJAX-ификация интерфейсов также планируется.

Придумал ее, разумеется, не я, а прочитал, кажется, у Джоела Спольски. Слышал, что ее дают на собеседовании в Microsoft. В коротком варианте она звучит так: «как повернуть строку задом наперед?». Подозреваю, что в Microsoft не ожидают ее решения на PHP, а вероятно, на С или С++. Прелесть задачи состоит в том, что она мало говорит о языке и много – о программисте. В моем варианте она звучит так:

<?php
$a = 'abcdefgh';
// Напишите здесь недостающий код, чтобы результатом работы скрипта была строка $a, повернутая наоборот
echo $a;
?>

То есть, этот скрипт должен выдавать

hgfedcba

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

Нет, правда, попробуйте.

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

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

4. Номер четыре занимает вариант «В PHP вроде должна быть такая функция…». Что ж, справедливости ради, должен сказать, что в PHP действительно есть такая функция. Названия ее, конечно же, никто не помнит. Это нормально. Но неужели вы думаете, что я задавал эту задачку, чтобы услышать такой ответ? Следом за таким ответом предлагаю реализовать эту функцию самостоятельно. То есть, как отмазка не канает, надо писать.

3. Место номер три уходит семейству решений под девизом «ну, как-то через массивы». Код при этом, разумеется, выглядит по-разному, и до победного конца (работающего и выполняющего задачу скрипта) добираются не все адепты массивных решений. Функции explode() и, соответственно, implode() приходят в голову далеко не всем, а уж что пытаются делать между ними – прямо стыдно рассказывать. Даже сортировку. Решение с массивами формально годится, задача должна быть в первую очередь решена, а потом уже можно и заняться оптимизацией, и поговорить о производительности, и так далее. Нюанс в том, что решить задачу через массивы не так уж легко, потому что массивы тут не нужны. Есть у меня подозрение, что такое решение говорит о том, что человек недостаточно работал с примитивными типами данных, а был в детстве ранен в мозг простотой и легкостью динамических массивов в PHP. Но человека, более-менее писавшего, например, на С, таким не обмануть. Так что в целом – подходу незачот.

2. Следующее решение – минимально адекватное для того, чтобы я рассматривал человека всерьез:

$b = '';
for ($i = strlen($a)-1; $i>=0; $i--)
    $b .= $a[$i];
$a = $b;

Возможны, понятно, некоторые вариации.

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

• strlen() вынесен из тела цикла и выполняется один раз (есть ли понимание того, что это зло?)
• минус один от длины строки (сколько шишек об это уже набито?)
• как там с ноликом – больше или больше-равно? (те же, в принципе, шишки)

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

1. Джедайские техники. Чемпионов видно по джедайским техникам решения задач, хочется верить, что такие люди хотя бы листали Кнута. Мне известно только две, на собеседовании я встретил их буквально один или два раза. Первая, которую я таки встречал (Вадим, привет) заключается в том, чтобы использовать цикл вдвое меньшей длины и менять местами соответствующие символы:

$b = '';
$l  = strlen($a)-1;
for ($i = 0; $i < $l/2; $i++) {
    $b = $a[$i];
    $a[$i] = $a[$l-$i];
    $a[$l-$i] = $b;
}

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

$a[$i] = $a[$l-$i]^$a[$i];
$a[$l-$i] = $a[$l-$i]^$a[$i];
$a[$i] = $a[$l-$i]^$a[$i];

Задачка, конечно, «плюшевая». Я сам могу придумать десяток причин, по которым она плоха – не отражает знание PHP, не соответствует реальной жизни, что вообще она показывает, бла, бла, бла. Как, например, понять, догадался человек о таком решении или просто читал о нем где-то еще? Неважно. Уверяю вас – пользуясь этой задачкой (и, конечно, еще многими другими) я еще ни разу серьезно не ошибся с кандидатом. Ведь формальное знание PHP в кандидате – поверьте, далеко не главное. Значительно важнее – отношение к своему занятию, стремление к развитию, способность играть в команде, видение мира, если угодно. Мне гораздо интереснее, как человек решает задачу, чем ее фактическое решение. Грань между этими вещами довольно тонка, но мне кажется – она есть, и понять, что за ней, не так уж просто.

А всем, кто дочитал до этого драматического места, я напоминаю, что наш проект ищет людей, которые обладают талантами PHP-программистов, которые в начале этой статьи все-таки решили эту задачку и ответ находится в первой или второй группе решений. Таким программистам мы хотим рассказать о прелестях работы в стартапе, о чудесах, на которые способна маленькая но мощная команда, вооруженная разносторонними знаниями, оснащенная лучшими средствами производства гениальных проектов и мотивированная нашими, украинскими, реальными рыночными целями. Если вы хороши, действительно хороши в PHP, и это не единственный ваш язык программирования, если у вас есть свое мнение относительно модели MVC и пара серьезных проектов за спиной, если вам не все равно как происходит развитие проекта, и вы болеете душой за agile, scrum и xp, если вы еще недостаточно закостенели и готовы броситься с головой в проект, где надо будет реально показать то лучшее, на что вы способны – то у нас есть к вам предложение мечты. Но задачка на собеседовании будет другая

Алексей Колупаев,
kolupaev@gmail.com