О чем молчит SCRUM (часть 2).

Июль 25th, 2010

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

Ну и теперь, возвращаемся к Scrum’у.

1) Один из тезисов Scrum’а состоит в том, что все что нужно — это дать команде самоорганизовать и она станет максимально эффективной. Вот скажите мне, если нанять 10 забулдыг, которые компьютер в жизни не видели, будет ли какой-то эффект от их самоорганизации? Ok, а если дать возможность 10 junior’ам самоорганизоваться, то станут ли они от этого вдруг производить высококачественный код и хорошо разбираться в архитектуре?

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

То есть, возникает вопрос. Какова должна быть команда, чтобы эффективность от самоорганизации хорошо прыгнула вперед. Где собственно описание того, на какой команде наиболее эффективно работает SCRUM, вопрос того, как нанять такую команду или что делать с текущей командой, для того, чтобы сделать из нее такую, на которой все будет хорошо работать? Об всем это Scrum скромно молчит.

2) Продолжаю тему команды. Все члены команды считаются team member’ами. Разделения между Dev и QA не проводится. Как вы понимаете, это происходит только на бумаге. QA не может эффективно делать Dev работу, а Dev не может эффективно делать QA работу. Почему мне не слишком нравиться эту ситуация, когда на бумаге одно, а в реальности другое? В такой ситуации значит, что хотели сказать что-то другое, но говорить напрямую было бы неприлично и поэтому мысль замаскировали. Так вот, мысль которую я хотели сказать (да и в сказали таки в многих местах), что Dev + QA __коллективно__ ответственны за проект и не имеют право валить на кого-то другого вину за неправильное или плохое исполнение.

Честно говоря, я не супер большой любитель коллективной ответственности. Опять же, это продолжение пункта N1. Коллективная ответственность хорошо работает на умных, добрых и ответственных людях и она может дать ооочень
плохие результаты (гораздо хуже чем при waterfall management’е) при безответственных и злонамеренных людях.

3) В прошлой статье я написал пример о том, что проект который уже ведется тяжело переводить на Scrum. Я с него и продолжу.

Итак ситуация такова, есть продукт с плохим (или средним) кодом, у этого продукта нету никаких тестов (ни unit, ни ui и ничего другого). А также этот продукт уже активно используют заказчики достаточно часто находя в нем баги (скажем несколько за неделю). Эти баги менеджеры очень хотят пофиксить быстрее, так как заказчики капризные и могут и нафиг послать. Ситуация естественно типична не для все фирм, но для множества продуктовых фирм.

Тут есть две проблемы — одна как работать с багами (которую я опишу тут) и вторая, как выпускать новые версии, которую я опишу в следующем пункте.

С багами можно работать тремя методами
а) Мы таки их по ходу включаем в Sprint. Обычно это учитывают с помощью focus factor (мы называли overhead). В целом работать может неплохо, если багов немного. Как только багов становится много (например команда тратит 30-60% от каждого sprint’а на них), то начинаются проблемы с тем, что sprint’ы становятся слишком непредсказуемы.
б) Можно команду разделить на Scrum — те, кто работают над новым и на support (которые будут работать по какой-то другой методике).
в) Можно таки попытаться откладывать баги на потом и планировать их по честному в следующий Sprint. Сразу скажу, что менеджмент и customer support будет против.

Тут в целом ничего военного, но тем не менее, в классическом описании Scrum’а — об этой проблеме не написано.

4) Когда команда работает над проектом с плохим кодом и без автоматизации тестирования, очень остро становится вопрос, как же сделать так, чтобы в конце Sprint’а можно было отдать заказчикам продукт. Проблема заключается в том, что для того чтобы отдать продукт нужно не просто протестировать 2 новые фичи, которые были сделаны, а еще регрессионно протестировать весь продукт, чтобы проверить ничего ли не было сломано.

Опять же решений несколько:
а) Отдельно от Scrum сидит команда тестировщиков, которые постоянно гоняют регрессионные тесты (до тех пор пока не будет достаточно количество автоматизированных и unit test’ов. Замечу, чаще всего обнаруживается, что QA очень сильно не хватает и нужно нанимать дополнительных людей (что не всегда по душе менеджменту).
б) Таки в конце sprint’а продукт не является shippable. И раз в 3-4 sprint’а таки делают большое перетестирование и пофикс багов. В результате получается скорее модифицированный waterfall, чем Scrum.

И моя стандартная фраза в этой статье — «Как обычно об этом тоже молчит Scrum»

Продолжение следует…

Posted in Менеджмент | 17 комментариев »

Если бы у меня было много триллионов баксов…

Июль 21st, 2010

Я бы их вложил в следующие области, которые мне лично крайне интересны.

Медицина/Биология:
— принципы старения
— принципы работы мозга
— серьезная генная инженерия

Физика:
— получение большого количества дешевой энергии

Космонавтика/Космос:
— межзвездные перелеты (сильно завязано на большом количестве энергии)
— поиски внеземных цивилизаций

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

Компьютерная техника + медицина:
— прямая работу мозга с компом (в обе стороны)

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

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

Posted in Деньги | 26 комментариев »

О чем молчит SCRUM (часть 1).

Июль 17th, 2010

Итак, начнем с начала. Почему, собственно я задумался об такой статье? Есть в Scum’е две вещи, которые меня конкретно нервируют.

— Как технарь и программист, я очень не люблю, когда мне говорят «делай только так, потому что так правильно» и при этом не объясняю почему именно так правильно, что будет если сделать не так. А все книги по SCRUM’у так и делают — выдают набор практик, артефактов, ролей и т.п., которые нужно использовать без малейшего объяснения для чего нужна каждая из этих деталей.

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

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

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

Приступим.

1) Передел территорий

Большинство SCRUM книг начинается с того, что рассказывается о том, какие есть роли в SCRUM’е и как надо начинать работать над проектом (составить backlog, перетасовать его по приоритетам и т.п.). Я не видел еще фактически ни одного источника, которые предлагает как «продать» идею внутри компании. В лучшем случае там пишется: Вася, CTO компании, решил попробоывать SCRUM.
Ну да ладно, умный человек всегда может выбрать с десяток пунктов, по которым SCRUM лучше waterfall и залив их большим количеством меда протолкнуть идею попробовать SCRUM в компании. Хотя и это было бы как-то описать, так как зачастую Вася не CTO в компании, а программист/тим лид/менеджер и соотвественно ему таки приходится пропихивать идею наверх.

Интересное начинается дальше. До тех пор пока SCRUM не стартован или только стартуется, все идет мягко и хорошо. Но вот возникает момент когда обнаруживается что
а) Project manager со всем своим длинным послужным списком PMP сертификатов не нужен, а нужен человек который прочел одну книжку и прошел двухдневный семинар Scrum мастерства. И не дай бог роль Scrum Master’а отдадут не Project Manager.
б) QA manager не нужен, так как внезапно QA становятся Team и теперь являются частью самоорганизающийся команды.
в) Вместо кучи Product manager’ов, маркетологов, sales’ов, которые постоянно совали нос в разработку пытаясь поменять порядок задач, теперь нужен один человек — Product Owner, который имеет право тасовать все задачи как ему вздумается (тут я немного преувеличил, но тем не менее, product managerская работа становится более видимой и их становится нужно меньше).
г) Программисты теперь не имеют право кивать на QA, что те чего-то не сделали. QA не имеел право кивать на программистов, что те чего-то не сделали.
д) Новый Scrum Master должен иметь БОЛЬШИЕ полномочия, для того чтобы расчищать путь для команды и водворять все стороны SCRUM’а. (в целом он конечно может бегать к мендежру каждый раз, когда нужно купить пишущих ручек, но это не так, чтобы слишком эффективно).
е) Лестница технического менеджмента тоже становится вроде как-бы и не слишком нужно, так как по сути они больше ни должны руководить.

Итого. Мы, что мы имеем? Мы протопталисья буквально всем по любимым мазолям, мы пытаемся отнять власть у /одних, выдать ее другим, вскрыть то, что кто-то пинает, а не работает и т.п. Как вы считаете, будут ли все вышеперечесленные очень рады нововведениям?

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

2) Второе, о чем почему-то редко говориться в Scrum, это о том как переводить проект с классического waterfall (или вообще отсутствия методологии) на Scrum. Опять же в большинстве книг рассказывается о том, что вот мол решили начать новый проект и попробовать Scrum. Извините… секундочку… То есть 80% рынка управления уже существующими проектами — нафиг из описания, а вот лучше мы опишем, как делать для остальных 20%, так как там поменьше зацепочек.

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

Коротенький пример по этому поводу. Представим себе, что у вас есть продукт который активно пользуют, и в течении 3 недель (вашего спринта) вам приходит 3-4 бага от заказчиков которые надо пофиксить как можно быстрее. Модель Scrum’а такое не поддерживает. Содержание текущего Sprint’а не может меняться. И в этом смысле, в новом проекте, легко сказать всем вовлеченным — если есть баг, то мы его кладем в Backlog и пофиксим в следующем Sprint’е, в старом проекте где всегда фиксилось в течении 2-3 дней, явно менеджмент и customer support не оценит идею пофикса через 2 недели.

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

Posted in Uncategorized, Менеджмент | 24 комментария »

Как развивать свою фирму?

Июль 15th, 2010

С пару недель назад, мне позвонил мой давний знакомый с которым мы уже добрых лет 7-8 не слышались и зашла у нас речь о freelance/небольших фирмочках.

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

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

Сразу скажу, нету у меня никаких данных, как «открыть глаза» лидерам таких команд и превратить маленькие конторы в IBM.

Начнем с начала:

1. Маржа прибыли

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

Если вы получаете X долларов и отдаете X долларов (включая вашу зарплату), то внезапно оказывается, что ваша прибыль равна нулю. И получается, что вы хотите получить что-то (рост) вкладывая ничего (0 долларов).

Безусловно, вы можете еще вкладывать время. Но опять же, если вы уже что-то делаете full time, то вам тяжело будет уделить больше чем дополнительные час-два в день (да и то они будут уже не слишком эффективные, так как вы будете откровенно уставшие).

Так вот, ситуация следующая. Для того, чтобы расти, ваша маржа должна быть достаточно большая. Поэтому поводу попытайтесь или поднять свой рейт или опустить растраты. Условно говоря, гораздо лучше иметь 2 наемных сотрудника и маржу прибыли 50%, чем 5 наемных сотрудников и маржу прибыли 10%.

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

Как я уже говорил, у меня нет Единственного_И_Правильного ответа, на то как поднять свой рейт. Само собой разумеющиеся вещи — поговорите о повышении оплаты с текущим заказчиком, попытайтесь пойти на oDesk и выставить цену часа выше текущей.

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

2. Нишевость

Для того, чтобы продавать свои услуги дорого, вам нужно быть в нише, где конкуренция не так велика. Условно говоря, из существующих 100 фирм небольших фирм, которые бьются за заказы — 20 будут заниматься PHP, 15 будут заниматься RoR, 10 будут заниматься мобильными разработками и т.п. Будучи в первой группе, вы конкурируете с 20 фирмами разбросанными по миру и в результате вас прижимают к рейту $10/час, находясь в третьей группе, вы уже конкурируете только с 10 фирмами и вас прижмут к рейту $15/час. Находясь в какой-нибудь седьмой группе, где есть всего 2-3 фирмы, вы сможете получать $25/час. Естественно, я упрощаю, так как есть еще и спрос, кроме предложения. Но в целом, в небольших нишах соотношение спроса к предложению, лучше чем в mainstream.

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

Кстати, еще одна вещь по поводу большая и малая команда (при одинаковых прибылях). Если у вас команда меньше, то вам проще перебраться в другую нишу.

3. Новые заказчики

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

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

Я бы сказал, что поиск заказов можно разбить на три уровня активности:

— Пассивный

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

— Слегка активный

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

Выжить тут можно, но если повезет и рост будет ну ооочень не спешный.

— Активный

Кто-то от фирмы ездит на конференции, выставки, активно «трется» с кучей разных фирм. А потом сидит на email’е и телефоне и пытается из них выбить заказы, договаривается о сотрудничестве и т.п. Плюс фирма участвует в закрытых или полузакрытых тендерах (до которых они опять же добрались через наработанные связи).

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

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

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

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

Posted in Старт бизнеса, Эффективность | 8 комментариев »

« Older Entries
Newer Entries »