Есть такой экономический закон: спрос (и часто цена) на товар растет, при снижении стоимости товаров дополнителей. Дополняющий товар - это товар, который обычно покупается вместе с покупаемым товаром. Бензин и автомобили дополняют друг друга.
Помните, как компания Microsoft завоевывала рынок? Они выпускали программное обеспечение, которое шло в дополнение к компьютерам. Но ведь с их точки зрения, - это компьютеры дополняли ПО. Они стремились сделать компьютеры взаимозаменяемыми, что снижало бы их стоимость и в свою очередь способствовало росту цен на софт и его распространению.
Если вы хотите на чем-то заработать, позаботьтесь о том, чтобы сопутствующие товары были широко распространены и взаимозаменяемы. Согласитесь - интуитивно понятно, что выгодно делать продукты платформо-независимыми. Чем дешевле будет железо или платформы и чем легче их можно будет поменять на другие, тем больше людей будет приходить к вам и пользоваться вашей продукцией.
Этот закон можно встретить повсеместно, но не столь просто его иногда увидеть. Например сложно понять, что разработчики и то, что они делают так же дополняют друг друга.
Проблемы разработки
Поговорим о процессе разработки программного обеспечения. Представьте фирму Elis по производству компьютерных игр. В ней трудятся люди самых разных специализаций: программисты, художники, дизайнеры, тестеры их руководители и много кто еще. Каждый сотрудник, выполнив свою работу становится единоличным обладателем уникального опыта и знаний о том, как в действительности она сделана. Чем больше человек делает, тем больше проект становится от него зависим. Это приводит к проблемам при разработке и неоправданным расходам. Что же тут можно сделать?
В команде люди всегда должны взаимодействовать друг с другом. Если людей всего двое, то всегда можно спросить как и что работает. Это самая лучшая, но крайне редкая ситуация. В действительности в нашей воображаемой фирме работает целая команда разработчиков над одним проектом. Люди специализируются на какой-то определенной деятельности и с головой в нее погружаются. Никто не утруждается написанием внутренней документации. Это никогда не планируется в проекте, а выделять свое собственное время на такие непонятные вещи никто не любит.
“Да и зачем?” - думают менеджеры. Это не принесет ни какой отдачи. Кроме того, в этой работе задействован только один программист Петя, а он и так все прекрасно знает. Если кому-то понадобится, разобраться в системе, то можно всегда спросить у него.
Возникает проблема с плохо заменяемыми сотрудниками. Если такой человек заболеет или уволится, то это может парализовать работу команды, пока кто-нибудь другой не вникнет в чужую работу. Вы конечно наслышаны о том, как тяжело разбираться в чужом коде. Но и для других направлений дизайна или арта это тоже справедливо. Сложно продолжать работу другого человека. Иногда это бывает вообще невозможно без него самого.
Но проект преодолевает мелкие трудности и начинает развиваться. Нужно подключать новых людей. Каждого нового сотрудника нужно ввести в курс дела, а иногда и научить работать. Это отвлекает опытных сотрудников и тормозить развитие проекта. Опять непредвиденные расходы времени и средств.
В целях ускорения работы менеджеры решают посадить Петю писать средства автоматизации, экспортеры, плагины к Photoshop’у и Maya. Он создает целый ворох вспомогательно инструментария признанного облегчить работу сотрудников. Но инструменты мало написать, нужно еще научить ими пользоваться, а иногда и заставлять их применять. Люди вообще неохотно начинают использовать что-то новое без крайней необходимости.
Конечно, сразу нечего работать не будет и к Пете, как к ответственному программисту потянется вереница художников или дизайнеров с вопросами о том, как и что нужно делать. В подобной ситуации у него просто не будет времени делать что-либо, кроме обучения других пользоваться его инструментами.
Со временем список проблем только растет:
- Люди забывают что и как делать, начинают опять изобретать велосипеды
- Петя сам забывает, как инструменты работают, доработки и внедрение инструментов на новом проекте затрудняется
- Новые сотрудники требуют еще и еще Петиного внимания и времени на обучение.
- Если Петя заболеет или уволится, то либо кому-то придется сидеть и разбираться в том, как это все работает, либо инструменты постепенно отомрут и посадят нового человека сделать их заново.
- Если программист решит вынести дизайнерам из кода некие параметры для настройки, то он получит те же проблемы, что и в случае инструментария. Нужно сначала всем объяснить как и что… А потом еще раз это все повторять по мере подключения новых людей и отключения чужой памяти.
Все это повышает многократно стоимость разработки больших проектов, пропорционально квадрату количества задействованных сотрудников. И тут на помощь приходит наш закон экономики. Чтобы облегчить разработку, нужно сделать сотрудников взаимозаменяемыми.
Взаимозаменяемые сотрудники
Но как этого можно достичь?
Во первых, нужно осознать это, как проблему. Форд однажды решил ее в автомобилестроении создав конвейер. Попытки применения конвейера при разработке ПО известны, как принцип “Водопадного планирования”. Не к чему хорошему такой метод не приводит. Но проблема тут только в методах. Нужно понимать цель.
А цель проста - если при возникновении проблемы можно будет поручить ее решение наименее занятому или любому другому сотруднику, то цена решения проблемы будет крайне низка. Если при возникновении проблемы можно с ней справится используя базу знаний фирмы, не отвлекая других сотрудников, то цена ее решения будет низка. Стремление минимизировать зависимости между работой и сотрудниками, приведет к повышению эффективности разработки.
Не беспокойтесь. В вашей команде по прежнему люди будут специализировать на чем то своем. Но важно понять те проблемы, которые действительно тормозят разработку и решать их.
Нужно писать документацию. Если есть какая-то работа, которая возникает систематически или у разных людей, то ее нужно задокументировать. Если настройку или сборку вашего проекта делает один человек, то позаботьтесь, чтобы была документация о том, как это нужно делать. Иначе, в случае чего, вы будите бегать и искать того, кто в состоянии собрать экстренный билд для посылки заказчику, когда человек ответственный за это в отпуске. Конечно, умные люди скажут, что у них все автоматизировано, но сборка - это не компиляция, которая должны быть автоматическая на сервере. Если вам заказчик позвонит и скажет “Соберите мне до завтра демо-версию игры с китайской локализацией, для демонстрации в Пекине нашим партнерам”, сможете ли вы выслать ему версию просто взяв с сервера? Или все же нужно будет кому-то ее специально готовить и следить, что отправлено будет то, что надо?.
Создавайте свою базу знаний, например в wiki. Если каждому новому сотруднику вы рассказываете одно и тоже, то запишите это один раз и давйте ему ссылку, а затем убедитесь, что он все понял. При создании нового инструмента пишите документацию по использованию еще до того, как кто-то увидит его в первый раз. Потратив два часа на документацию вы сэкономите себе дни, потраченные на объяснения дизайнерам как и что должно работать.
Проводите мастер-классы и Best-Practice в компании, записывайте все это в базу знаний, с которой должны знакомиться новички или люди решающие проблему.
Презентуйте свои результаты. Каждый сотрудник должен иногда проводить презентацию того, над чем занимался; как и что сделал; какие проблемы у него возникали и как он их решал. Это даст другим представление о работе чужих модулей. Кроме того, на подобных презентациях можно не только задавать вопросы, но и давать советы по улучшению системы. Когда люди будут знать, что результаты и свои решения нужно будет презентовать, то они ответственнее подойдут к своей работе.
- Если результат работы одного человека используется другим, то процесс использования должен быть задокументирован.
- Если работу нужно делать больше чем один раз или более чем одним сотрудником, то пишите документацию. Иначе каждый потратит кучу времени на создание своего велосипеда, и придется еще решать проблему унификации результатов.
- Если вам дважды задавали один и тот же вопрос, то он достоин быть задокументированным.