Вчера на одном дыхании прочел книгу под названием «RTFM» (она на русском, всего 100 страниц). Очень рекомендую прочитать. Книга о том, как правильно строить сервисный бизнес.
Сказано в книге все правильно и умно, но я бы сказал, слегка упрощенно. Упрощенно в смысле, что автор дает правильный метод работы, но абсолютно опускает проблемы, которые возникают даже при правильном методе работы.
Тем не менее, еще раз рекомендую прочитать книгу. Кстати, а вот и блог автора — блог.
Второе, хочу дать ссылочку на статью (теперь уж на английском) — Avoiding Development Disasters. Очень точно описываются почему большие и слишком хорошо финансированные проекты чаще всего заканчиваются полным крахом.
И третья, мысль, которая вышла из вчерашнего спора с другом. Очень многие (особенно хорошие) разработчики говорят, что код должен является единственной и главной документацией (самоописывающий код). Что если нужно создавать отдельную документацию — это плохо, так как появляется второе «отображение» кода, которое может не обновляться и устаревать и расходится с кодом, что только усложняет понимание.
Я с этим категорически не согласен. Только небольшой проект очень хорошего написанного и прокомментированного кода можно понять без дополнительной документации. Когда же у вас на руках проект с миллионом строк кода, то для того, чтобы понять что и где происходит зачастую нужно будет проглядеть пол проекта (прилагая много усилий по удержанию в голове того, что вы еще видели и ни с чем не связали). При этом простая диаграмка, показывающая разбиение на модули и помудульная диаграмка, которая показывается основные взаимодействия внутри модуля может сохранить дни (если не недели), на том, чтобы понять, как проект работает.
О… Пока писал, еще одна мысль всплыла. Опять же, у программистов зачастую есть проблема ownership’а. То есть, они чувствуют, что владеют/отвечают за какой-то кусок работы. И постепенно в этом куске работы, они начинают делать все так, чтобы ИМ было удобно (не думаю о остальных, учитывая что они сами работают над этим участком). Мысль, которую я некоторое время назад сформулировал — владеть нужно проблемой и за нее отвечать, а код должен таки оставаться общий. Именно поэтому код должен комментироваться, документироваться и придерживаться другими методами доступным для остальных разработчиков.
Есть у меня пару человек, которые активно мне поставляют… нет не дурь (сами видно, заразы все выкуривают), но забавные корпоративные истории. Так, что выкладываю одну из них, буквально с минимальной обработкой. Все повествование ведется от лица поставщика (местами даже диллера 🙂
__________
В общем, преамбула совмещается с фабулой и будет многа букаф. Это скорее просто жалобы на тяжелую жизнь, но возможно тебе это знакомо. Короче говоря, у меня нас есть несколько тимов, каждый из которых пишет свой продукт и OEM тим, которые все эти продукты собирает, кастомизируют и раздают оем клиентам. Рулит этим тимом Configuration manager.
На прошлой неделе наш Configuration manager поднял плач Ярославны «как у нас все хуево с качеством, всем пиздец». Ну ок. В целом, я с ним согласен, но почему так получилось — вопрос интересный. Получилось так, что по целому ряду стратегических решений топ менеджмента, принятых год-полтора назад, стандартный подход — нахуй качество, надо рынок завоевывать, а остальное потом исправим. Ну, рынок завоевали, тока теперь на поддержание этой кучи говна в жизнеспособном состоянии тратятся огромные ресурсы, кастомизации под каждого клиента приходится приделывать болтами и сварочным аппаратом где-то сбоку.
Так вот, прошлонедельный плач был по поводу того, что тестеры из оем находят много багов, относящихся к самому продукту. И мы мол не знаем, что именно получает команда оем от команд продуктовых. Наш Configuration менеджер поднял дискуссию на высоком уровне и в итоге наш VP engineering’а произнес сакраментальную фразу: «А давайте померяем качество!»
Ну давайте. Встречный вопрос — а как мы будем мерять качество? Он грит, а хуй его знает. Вот пойдите, мои верные слуги, простите, менеджеры, и придумайте, как мы будем мерять качество. Мол, похоже QA хуево работают, но хер его знает. Мне изначально было все это похую, потому как я за qa не отвечаю и вообще это проблемы project manager’а.
В общем, как тут принято начинать работу над любым вопросом (хоть формы зеркала в сортире)? Правильно — соберем митинг. Пригласим всех ну или не всех. В общем, собрались мы митинговать — я, мой начальник, Configuration менеджер, директор инжениринг и прочая братия.
Project manager говорит — тебе нужно сказать, что ты как product manager хочешь сделать для измерения качества? Я говорю, охуенные заявочки. А ниче, шо инжениринг — это вы, а не я? Я вам как product manager могу тока сказать, что качество наверное хуевое, а как его мерять — это уже ваши дела. Померяйте и принесите. Они грят -а мы не знаем, как мерять качество. Вот если нам скажут, как мерять, мы померяем, и отчитаемся о проделанной работе.
Тут вступает Ленский, в смысле Configuration менеджер. Мне, сообщает, все равно, как и кто будет мерять, но мне надо, чтобы когда моему тиму сдают в релиз продукт, сообщали, какое у него качество. и так, чтобы было четко и понятно. а еще лучше говорит, чтобы ты сам там со своими пацанами разбирался, задерживал релизы, а мне приносили тока когда все готово.
Мой начальник, понимая, что эта хуйня и его касается, воспользовался авторитетом и послал их нахуй тут же с таким предложением. Мол, наша задача вообще ставить задачи и acceptance criteria. а то что вы там в своем инжениринга собрались мерять — это вы там сами разбирайтесь.
Короче этот волейбол продолжался два рабочих дня. В промежутках между этими безумно продуктивными дебатами я (хаха, наивный мальчег) ходил по людям и пытался найти, кто вообще обладает подобными знаниями и отвечает за эти вещи. пошел сначала к инженирингу. они замахали руками, зажмурились и закричали «не, мы сами нихуя не знаем». ну ладно, пошел к QA. QA менеджерша перепуганным голосом сказала, что она сделает все, что ей скажут, особенно если расскажут, как делать.
Мне все это надоело, я пошел к моему боссу и говорю — вот такая хуйня. Я в жизни никогда qa не был, какие у них там метрики, методы и тд я понятия не имею. Он говорит, ладно, ну их всех нахуй. Раз никто нихера не знает, будем сами с тобой придумывать. Собрали очередной митинг. Вызвали все тех же танцоров.
Началось все уже привычно: А как нам померять качество? Я грю, ну самое простое, что приходит в голову — отсортировать тест кейсы по группам и собрать статистику по pass & fail. Все радостно закивали головами. Но тут вступил мой босс. Не, говорит, это все хорошо, но не люблю я эти тест кейс статистики. Вот когда я пишу acceptance criteria, я знаю, что это я написал и знаю, сколько они покрывают. а кто там писал ваши тест кейсы я не знаю, и как они написаны я тоже не знаю. Может они там покрывают 20% возможных use cases (надо заметить, у него есть основания так говорить). Давайте, говорит, лучше определим 10-20 основных функциональных областей (типа как epics), отдадим каждому члену команды на тестинг и послушаем выводы.
Тут вступает project manager: не, если программистов послушать, так у них все работает идеально, а если не работает, то это исключение и дурацкий юз кейс (что впрочем, тоже логично).
Я говорю, а может мы не будем изобретать велосипед? Судя по всему,никто из нас не знает, что значит померять качество. Но вполне возможно, есть какие-то работы на эту тему, подходы, тулзы. Я даже готов почитать это все, чтобы с умным видом всех вас просветить позже. даже если нихуя там нету, что тоже может быть. Но естественно это не могло пройти, потому как Configuration менеджер тут же застонал, что у него сейчас релиз, а как мы вообще можем релизить, не зная качество, так что померять надо прямо сейчас и срочно.
Я говорю, а как мы до этого релизили? На что следует ответ: ну так это же было неправильно! Мы же растем, мы должны знать, что мы релизим. Ок, отвечаю я, а как на счет того, чтобы мы сейчас неправильно отрелизили по старинке, не страдали хуйней, а по ходу следующих несколько недель я почитаю, подумаю, да и вообще что-то придумаем. Он на меня посмотрел так, как будто я лично признался в массовых убийствах христианских младенцев и сообщил: ТЫ ЧТО, ХОЧЕШЬ РЕЛИЗИТЬ, НЕ ЗНАЯ, ЧТО ТЫ РЕЛИЗИШЬ??? И ЭТО НЕ СГНАЛ ТРЕВОГИ ДЛЯ ТЕБЯ???
Бля, чувак, да у нас под тысчу открытых багов. Я знаю, что мы релизим полное гавно и мы его не разгребем сейчас. И скорее всего никогда не разгребем, потому как у нас одни обязательства. Да, отвечает он,- но мы хотя бы сможем померять и будем знать, что и как в общем, громко поплевавшись мы решили совместить наши гениальные идеи. Решили, что я напишу список критичных функциональных областей, отправлю тимам, инженеры с их менеджерами решат, что и как делать, а дальше по каждой из этих областей мы соберем и проценты по тест кейсам и общие наблюдения. Из-за этого релиз был торжественно отложен. Как же релизиться, если не померяли?
И теперь финишная прямая
Я написал письмо, отправил тимам с их инженерным менеджментом, а он — менеджмент тот — пришел ко мне и сказал: а мы че-то не поняли, в каком виде вы это хотите получить? @#$@#$@#$…. В виде процента по тест кейсам бля и личным соображениям бля. Хотя я думал, вы там что-то с QA придумаете. Ответ последовал ожидаемый: так а шо QA, они качество мерять не умеют. Как скажете, так и померяем.
Я устало махнул рукой, и сказал — ну вот пусть и меряют по своим тест кейсам.
Мой брат у себя в блоге написал интересный вопрос по поводу того, откуда берется объем рынка.
Собственно, вот то, что он написал.
В чем действительно для меня загадка современной экономики — так это в том, откуда в ней берутся деньги… Даже не так. Не деньги — а адекватное товару количество другого товара, с помощью которого можно через деньги обменяться всем со всеми. Мудрено?
Попытаюсь попроще. Я думаю все в курсе что главный вопрос современной экономики это не произвести какую-то вещь, а найти того, кто ее согласен купить за те деньги что ты хочешь ее продать. Скажем, сейчас в развитых странах не проблема произвести продуктов питания в десять раз больше того количества что есть сейчас. Проблема что это просто не купят и не сьедят. И машин можно не сделать, так привезти вдесятеро больше — опять же, не купят. То есть получается, что нужно во первых обнаружить и опылить все мыслимые ОПЛАЧИВАЕМЫЕ потребности, но с другой стороны — считаться с обьемом рынка. Вот у меня собственно и вопрос — а откуда берется этот обьем рынка. Ну, в определенных вещах он достаточно ясен — человек не сможет сьесть больше пяти килограммов бананов, как его не мучай, или, скажем, человеку обычно не нужны пять машин чтоб ездить.
Но все равно — емкость рынка зависит от предыдущего состояния этого рынка — а тот от предыдущего, и так далее. Скажем, американский автомобильный рынок — огромный, с дешевыми ценами. Откуда это? Насколько далеко в прошлое придется уйти чтоб понять феномен американского богатства? Почему Гаити нищая страна? Почему Доминикана, находящаяся в тех же буквально условиях — гораздо богаче?
Собственно, вопрос меня заинтересовал тем, что я сам давно хотел написать «симулятор» экономики (что-нибудь на базе цепей Маркова, если я не пумаю название). И с помощью этого симулятора, можно было бы глядеть, куда, как и почему ползут деньги. Но, само собой, времени как обычно нет. Так что, приходится все моделирование проводить в голове.
Итак, начну с того, что стоит рассматривать сначала весь рынок целиком. Так, как пытаться сейчас выделить одну страну достаточно сложно, учитывая гигантское количество импортно/экспортных связей с другими странами.
Зарисовка 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 лет накопился отрыв в размерах рынков в сотнях раз.
Я подозреваю, если для размера всемирного рынка, можно апроксимировать и вывести какую-то формулу, которая его будет более менее описывать, так как он скорее зависит от крупных событий (которых меньше). То размер локальных рынков зависит от глобальных событий плюс от локальных событий и поэтому гораздо сложнее докопаться до первопричин, которые повлияли на его становление.
Знаю, что для людей проживающих в Украине и России не так актульано, но тем не менее.
Страховка выгодна только в одном случае, когда потенциальные траты по происшествию события (от когорого страхуемся) гораздо больше чем вы себе можете позволить.
Например, имеет смысл страховка жилья или авто. Так как $10k+ (а может и $100k+) — это очень болезненный «удар». Гораздо легче переживается запланированные $100 в месяц.
И абсолютно не имеет смысла покрывать стаховкой какие-то события которые грозят не слишком большими деньгами.
Подумайте о том, что в страхующей компания получает деньги на том, что высчитывает вероятность событий. И вероятнее всего она это сделает лучше чем вы. Соотвественно, стоимость страховки всегда расчитана так, чтобы в среднестатистическом случае вы потратили на нее больше, чем из нее получили. Поэтому среднестатистически вы теряете деньги на каждой купленной страховке.
