Вчера на одном дыхании прочел книгу под названием «RTFM» (она на русском, всего 100 страниц). Очень рекомендую прочитать. Книга о том, как правильно строить сервисный бизнес.
Сказано в книге все правильно и умно, но я бы сказал, слегка упрощенно. Упрощенно в смысле, что автор дает правильный метод работы, но абсолютно опускает проблемы, которые возникают даже при правильном методе работы.
Тем не менее, еще раз рекомендую прочитать книгу. Кстати, а вот и блог автора — блог.
Второе, хочу дать ссылочку на статью (теперь уж на английском) — Avoiding Development Disasters. Очень точно описываются почему большие и слишком хорошо финансированные проекты чаще всего заканчиваются полным крахом.
И третья, мысль, которая вышла из вчерашнего спора с другом. Очень многие (особенно хорошие) разработчики говорят, что код должен является единственной и главной документацией (самоописывающий код). Что если нужно создавать отдельную документацию — это плохо, так как появляется второе «отображение» кода, которое может не обновляться и устаревать и расходится с кодом, что только усложняет понимание.
Я с этим категорически не согласен. Только небольшой проект очень хорошего написанного и прокомментированного кода можно понять без дополнительной документации. Когда же у вас на руках проект с миллионом строк кода, то для того, чтобы понять что и где происходит зачастую нужно будет проглядеть пол проекта (прилагая много усилий по удержанию в голове того, что вы еще видели и ни с чем не связали). При этом простая диаграмка, показывающая разбиение на модули и помудульная диаграмка, которая показывается основные взаимодействия внутри модуля может сохранить дни (если не недели), на том, чтобы понять, как проект работает.
О… Пока писал, еще одна мысль всплыла. Опять же, у программистов зачастую есть проблема ownership’а. То есть, они чувствуют, что владеют/отвечают за какой-то кусок работы. И постепенно в этом куске работы, они начинают делать все так, чтобы ИМ было удобно (не думаю о остальных, учитывая что они сами работают над этим участком). Мысль, которую я некоторое время назад сформулировал — владеть нужно проблемой и за нее отвечать, а код должен таки оставаться общий. Именно поэтому код должен комментироваться, документироваться и придерживаться другими методами доступным для остальных разработчиков.
Мой брат у себя в блоге написал интересный вопрос по поводу того, откуда берется объем рынка.
Собственно, вот то, что он написал.
В чем действительно для меня загадка современной экономики — так это в том, откуда в ней берутся деньги… Даже не так. Не деньги — а адекватное товару количество другого товара, с помощью которого можно через деньги обменяться всем со всеми. Мудрено?
Попытаюсь попроще. Я думаю все в курсе что главный вопрос современной экономики это не произвести какую-то вещь, а найти того, кто ее согласен купить за те деньги что ты хочешь ее продать. Скажем, сейчас в развитых странах не проблема произвести продуктов питания в десять раз больше того количества что есть сейчас. Проблема что это просто не купят и не сьедят. И машин можно не сделать, так привезти вдесятеро больше — опять же, не купят. То есть получается, что нужно во первых обнаружить и опылить все мыслимые ОПЛАЧИВАЕМЫЕ потребности, но с другой стороны — считаться с обьемом рынка. Вот у меня собственно и вопрос — а откуда берется этот обьем рынка. Ну, в определенных вещах он достаточно ясен — человек не сможет сьесть больше пяти килограммов бананов, как его не мучай, или, скажем, человеку обычно не нужны пять машин чтоб ездить.
Но все равно — емкость рынка зависит от предыдущего состояния этого рынка — а тот от предыдущего, и так далее. Скажем, американский автомобильный рынок — огромный, с дешевыми ценами. Откуда это? Насколько далеко в прошлое придется уйти чтоб понять феномен американского богатства? Почему Гаити нищая страна? Почему Доминикана, находящаяся в тех же буквально условиях — гораздо богаче?
Собственно, вопрос меня заинтересовал тем, что я сам давно хотел написать «симулятор» экономики (что-нибудь на базе цепей Маркова, если я не пумаю название). И с помощью этого симулятора, можно было бы глядеть, куда, как и почему ползут деньги. Но, само собой, времени как обычно нет. Так что, приходится все моделирование проводить в голове.
Итак, начну с того, что стоит рассматривать сначала весь рынок целиком. Так, как пытаться сейчас выделить одну страну достаточно сложно, учитывая гигантское количество импортно/экспортных связей с другими странами.
Зарисовка 1.
Представим себе, что у нас есть рынок из одной компании (которой владеют инопланетяне и не вмешиваются в нее) и одного работника (само собой весом 1 кг и ростом 1 м). Условно говоря, у компании есть $100. Работник делает 1 unit в год. За это ему платят $100. Но беда рабочего состоит в том, что для проживания ему надо потреблять 1 unit в год. Соответственно, он покупает его назад (цена которую поставили инопланетяне — $100 за unit). Итого, все крутится по кругу, он работает, производит, получает деньги, покупает произведенное и потребляет. Общий размер рынка $100.
Тут возникает первый прикол. Если, бы инопланетяне обладали $1000, платили зарплату $1000 и поставили цену $1000, то точно также происходит круговорот, только размер рынка был бы $1000. Это я так, намек на то, что сами деньги на самом деле относительная, а не абсолютная единица. Так что, нужно быть аккуратным с оценкой рынка в относительных единицах.
Так что, уж лучше я скажу, что рынок составляет 1 unit. Хотя секундочку. Ведь, если бы рабочий производил и потреблял 10 unit’ов — опять же был бы тот же круговорот. Вывод, и unit’ы оценка относительная.
Тут мысль перескакивает, но она еще вернется.
Как этому бедолаге жить лучше? В обычной ситуации ответ — если он получает больше денег, то жить будет лучше, но тут у нас закавыка. Во первых больше денег нет (всего в системе $100), а во вторых больше за них покупать и нечего (всего в системе 1 unit). Само собой, единственный метод — это чтобы он производил больше чем потреблял.
Представим себе, что он может производить 10 unit’ов, а минимальные потребности у него 1 unit. Соответственно, теперь инопланетяне ему могут платить $100 и поставить цену $20 за unit (вопросы о монополии труда и рабочей силы оставим пока за рамками). Итого, получается, что инопланетяне теперь могут увозить к себе на Сатурн по 5 unit’ов в год, а товарищ стал жить лучше (вместо минимального потребления в 1 unit, он потребляет теперь в 5 раз больше).
А теперь возвращаемся к оценке рынка. Я бы сказал, что его нужно оценивать в количестве минимального потребления. Соответственно, в изначальной ситуации рынок был равен 1 (1 unit производства/1 unit — минимальное потребление), в тот момент, когда человек начал производить 10, то рынок стал бы 10 (10 unit производства/1 unit — минимальное потребление) .
Что сразу бросается в глаза, что рынок зависит от эффективности человека. Эффективность в нашем случае это соотношение его производства к минимальному потреблению.
Кстати, этот ответ большинство людей приводят быстро и не хотят двигаться дальше него.
Зарисовка 2.
Все предыдущие размышления касались товаров для получение единицы которых нужно потратить одинаковое количество труда (например — еда, машина). Теперь, представим себе товар, который прекрасно дуплицируется (например компьютерная программа). Написать программу занимает какое-то время, но как только она написана, нам не нужно дополнительного времени для получения второй, третьей или X-ой копии программы.
Итого, мы теперь имеем компанию N1 (которой владеют инопланетяне с Сатурна) и компанию N2 (которой владеют инопланетяне с Юпитера). На одну работает работник N1, на вторую работник N2. У одной компании есть по $200, а у другой $100. Зарплаты $100. Выпускается 1 unit бесконечно дуплицирующегося товара. Причем компании выпускают такой товар, который безумно нужен другой компании и которые те купили бы в бесконечном количестве экземпляров.
Происходит следующее. Работник 1 и работник 2 делают по одному unit’у и получают свои $100. Одна компания осталась при $100 у второй денег нет. Обе компании имеют по этому продукту, которые они хотят продавать.
Теперь, компания без денег продает свой продукт другой, получает за него $100. Те в ответ продают свой продукт и получают назад $100. Первая снова продает продукт и получает опять $100 и т.п. до бесконечности.
Чему у нас равен рынок? Вроде он равен бесконечности (так как они могут перепродавать друг другу до бесконечности эти unit’ы). Но на самом деле он зависит от скорости продаж. Чем выше скорость, тем больше рынок. Чем скорость ниже, тем рынок меньше.
Итого, что мы имеем, что объем рынка зависит от легкости дублицирования продукта и от скорости продаж.
Дальше пойдем без зарисовок.
Из первой сценария было понятно, что рынок зависит от эффективности. Но на самом деле эту эффективность надо разбить на несколько разделов:
— персональная эффективность (умения, знания, настрой на работу и т.п.)
— эффективность средств производства (на трактаре пахать легче, чем на лошаде).
— управленческая эффективность (насколько хорошо выстроена цепочка управления над человеком до верхушки компании, а пожалуй и включая часть государственной цепочки).
— маркетинговая эффективность
Когда изобретение делают в Гарварде, то оно патентуется и через 5 лет приносит кучу денег, а когда оно делается в НИИ Обырвалг в Нижнем Урюпинске (то дай бог, об нем узнают 5 человек). Изобретение может быть одно и тоже, но важно насколько хороша уже построенная сеть по сбыты товара/изобретения и насколько быстро все продвигается через эту сеть.
Я бы сказал, что вот эти четыре перемноженных эффективности дают общую эффективность. И именно они влияют на размер рынка.
Теперь слегка о ограничениях.
Все это хорошо, но то о чем я говорю скорее показывают максимально возможный размер рынка.
В целом на него накладывается два серьезных ограничения
— потребости
Как писал мой брат, произвести то можно в пять раз больше еды, только вот съесть в пять раз больше нереально.
— конкуренция
В тех зарисовках, которые я привел, все произведенное потреблялось. Естественно в реальных условиях, одни товары будут конкурировать с своими прямыми конкурентами или непрямыми (учитывая ограниченное количества денег у покупателя) и что-то будет не куплено.
Думаю, можно копать было бы и глубже. Но и так уже вышла не статья, а колбаса какая-то. И вроде самые крупные вещи я охватил. Если я пропустил что-то из крупных факторов влияющих на размер рынка, с удовольствием выслушаю дополнения и замечания.
Ну и возвращаясь к вопросы, почему одна страна богатая, а другая бедная. Тут мне кажется дело в истории. Условно говоря, 200 лет назад две страны могли быть очень похожи. Какие-нибудь небольшие разницы в события (чуть различные по кровожадности диктаторы, чуть разные состав населения) приводит к тому, что несколько из вышеуказанных факторов начинают различаться. И условно говоря достаточно 2-3% разницы, чтобы за 200 лет накопился отрыв в размерах рынков в сотнях раз.
Я подозреваю, если для размера всемирного рынка, можно апроксимировать и вывести какую-то формулу, которая его будет более менее описывать, так как он скорее зависит от крупных событий (которых меньше). То размер локальных рынков зависит от глобальных событий плюс от локальных событий и поэтому гораздо сложнее докопаться до первопричин, которые повлияли на его становление.
Со мной связался Alex, который представляет Бизнес клуб и мы договорились, что я выложу его статью с ссылкой на их website.
Насколько я помню, ситуация для моего блога беспрецедентная. Слишком я большой графоман ;), чтобы активно выкладывать чьи-то статьи.
Тем не менее, так как статья хорошо ложится в размер моего блога, представляю ее ниже с некоторым количеством моих комментариев.
Каждый разработчик в своей практике наверняка сталкивался с такими ситуациями, когда работы по проекту все выполнены, продукт готов, а заказчик отказывается платить. При этом могут следовать заявления, что конечный продукт должен быть совсем другим, совершенно противоположный текущему. Порой на заказчика не действуют даже такие аргументы, что все работы выполнялись в рамках утвержденного обеими сторонами технического задания и результат полностью соответствует зафиксированным на бумаге положениям.
Как показывает практика, подавать в суд в таких случаях на заказчика, в основном является не эффективной мерой. Как правило, суд принимает сторону заказчика, и компания разработчик остается ни с чем. В итоге вы несете убытки, а ваш заказчик уходит к другому исполнителю, попутно заявляя всем о вашей некомпетентности.
От Виктора Ронина: Описанная ситуация действительно до боли знакомая. В момент, когда была фирма проходили ее не раз (хотя, что уж там, чаще всего по своей таки вине.
Я уже писал, что по моему мнению ситуация с судебной системой в exUSSR все еще не слишком хороша. Судиться с иностранными заказчика сложно. Однако, в случае, если таки добраться до суда в развитой стране, то суд вероятнее всего примет решение базируясь на том, что было подписано.
Насчет заявлений о вашей некомпетентности. Все зависит от области в которой вы работаете, но в целом для большинства областей количество потенциальных заказчиков настолько велико, что заявления о вашей некомпетентности, вряд ли снизят вероятность нахождения новых проектов.
В других ситуациях, заказчик может принять продукт, но все равно отказаться производить оплату сославшись на те или иные причины, которые указывают на то, что проект не доведен до конца или содержит массу ошибок, ожидать исправления которых, у него нет ни времени ни желания. Такой расклад можно считать сродни воровству. Тем более, что в последствии доказать авторские права крайне сложно. Так как ваш клиент может заявить, что не вы один предложили подобное решение, или что таковое уже было разработано до вас.
Рецепт от таких проблем может быть только одни – старайтесь не устанавливать подобные деловые контакты. Перед приемом проекта на реализацию тщательно изучите вашего клиента, выясните историю предыдущих заказов (если таковая имеется), поинтересуйтесь сколько проектов были завершены успешно. Если ожидается крупный проект, то не лишним так же будет связаться с исполнителями других проектов и попытаться выяснить у них, на сколько адекватен ваш клиент, были ли случаи мошенничества или уклонения от оплаты.
От Виктора Ронина:
Мне кажется, что подобная политика по идеи хороша, но крайне тяжело выполнима маленькими компаниями работающими над небольшими проектами, которые им дают другие маленькие компании. Проблема состоит в том что резко может вырасти время на «обработку» входящих проектов.
Каких заказчиков стоит избегать?
1. Ваш клиент не знает чего он хочет
Та категория заказчиков, которые не могут себе четко представить рамки проекта или суть проекта в целом. На протяжении всего времени работ их требования будут постоянно изменяться. Вам придется, то что-то доделывать, то где-то упрощать. И этому не будет конца. В итоге такой проект может зайти в тупик и в результате провалиться.
От Виктора Ронина: Абсолютно согласен. Если вы видите, что клиент не уверен хочет он делать вертолет или самолет — это очень плохой звоночек.
2. Ваш клиент хочет больше чем может себе позволить
Увлекшись, ваш заказчик начинает требоваться все больше и больше. Видя ваше желание сделать проект лучше угодив клиенту, он может начать требовать еще и еще. В итоге вы либо сделает больше, чем это было определено бюджетом проекта и сработаете себе в убыток, так как заказчик в результате скажет, что у нас был бюджет и не стоит ему сейчас рассказывать о дополнительной оплате. Либо когда вы все-таки решитесь отказать в очередной доработке, клиент может воспринять это негативно. Поэтому важно сразу четко дать понять заказчику, на какой объем работ он может рассчитывать в рамках установленного бюджета проекта.
От Виктора Ронина: Тут решение простое — хочешь изменения, вперед переходим на time & materials, хочешь без изменений — работаем по fixed price.
3. Клиент хочет совсем не то, что, как вы думаете, он хочет
Может сложиться очень опасная ситуация особенно если факт расхождения видения проекта заказчиком и исполнителем вскроется близко к завершению проекта. Ситуация может быть очень плачевной для исполнителя. Так как, чья тут будет вина, что разработчик не понял что нужно сделать? Поэтому еще на этапе проектирования не стесняйтесь задавать вопросы вашему клиенту, не стоит делать ставку на какое либо кажущееся полное «взаимопонимание», лучше лишний раз оговорить волнующие вас моменты, чтобы потом не пришлось все исправлять. С другой стороны, если вы изначально зафиксируете требования заказчика, ему будет сложнее их изменить в будущем, а вам всегда будет на что сослаться в случае возникновения подобных ситуаций.
От Виктора Ронина: Согласен. Я когда-то писал о чем-то похожем, что при работе с клиентом нельзя ничего подразумевать, так как то что вам кажется очень правильным и логичным, клиент может считать полной фигней и безумством (и наоборот)
Создавая свой успешный бизнес вы столкнетесь еще с множеством проблем и недобросовестные клиенты лишь одна из них. В любой ситуации, какой сложной вам бы она не казалась, стоит сохранять спокойствие и пытаться найти конструктивное решение. Анализируйте ситуацию, старайтесь просчитать свои ходы наперед, спрогнозируйте все возможные риски и пути выхода из таких ситуаций. Чем лучше вы подготовитесь, тем наиболее вероятным будет успех!
От Виктора Ронина: Мне кажется пропущен один важный вопрос. Что же делать если вы добрались таки до момента, когда заказчик не хочет платить (не все случаи удастся предотвратить). Но об этом я как-нибудь напишу отдельно.
