Об эффективном процессе разработки программного обеспечения

Чем одна компания отличается от другой? Почему заказчики с удовольствием заказывают у одной компании, но совершенно не замечают другую? Почему одна компания разрабатывает софт полтора года, а другая управляется всего за полгода? Есть множество причин, но всех их объединяет одна особенность – успешные компании эффективны. О том, как повысить эффективность компании на базе её отдельных составляющих, поговорим в этой статье.

Инфраструктура и инструменты

Типичные проблемы, связанные с инфраструктурой:

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

Такие проблемы решаются (должны решаться) очень просто: у вас должен быть аккаунт на Microsoft Azure или Amazon для развертывания своих веб-проктов и API, должны быть тестовые устройства на всех популярных (и, в идеале, не очень популярных) операционных системах. Софт можно получить по подписке, взять в аренду или (вы не поверите!) купить.

Главная цель всего этого процесса: максимально быстро дать первый ответ потенциальному клиенту на его запрос. Чем меньше времени у вас пойдет на развертывание и оценку – тем лучше.

Как-то мне понадобился сервер. Ну не то, чтобы мне лично он понадобился, а скорее, для проекта, который я вел, но можно сказать, что он мне понадобился. Я поступил, как истинный ариец, и написал своему начальнику о том, что мне нужно и зачем. После небольшой паузы (недельки две) меня попросили написать то же самое, только вышестоящему начальству, что было сделано незамедлительно. Прошло еще немного ктвремени (около месяца), когда мне пришло письмо о том, что я недостаточно убедительно обосновал необходимость сервера. Тогда я написал, что, в принципе, не так уж сильно мне сервер и нужен, да и ноутбук, в общем-то, излишество, да и хочу я отвлекать от важных занятий своими глупыми запросами. Сервер месяцев через три таки нашли (взяли старый комп, на который сотрудники отдела хранили порнушку), а проект с таким подходом, естественно, благополучно загнулся через какое-то время.

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

В отделе кипит работа – до дедлайна осталось совсем чуть-чуть, а развернуть продукт на тестовом сервере никак не удается. Над этой проблемой ломают голову лучшие умы – два архитектора, техлид и старший разработчики. Вся загвоздка в памяти — при деплойменте на тестовый сервер её просто не хватает и скрипт, отлаженный на локальных серверах, пестрит сообщениями об ошибках. Так продолжается уже несколько дней и начальство уже, мягко говоря, не в юморе… Проблема оказалась в том, что один из модулей был неверно сконфигурирован, что повлекло за собой генерацию множества отладочной информации, что « забивала» всю доступную память. «Ручная» отладка не помогла идентифицировать правильный модуль. Это сделала специальная программа – отладчик одного вендора, которая была установлена на локальную машину и уже через пять минут показала, какой из модулей отказывался нормально работать. Начальство оценило мой скромный вклад в решение проблемы и уже через несколько дней купила лиценции этого продукта для всех разработчиков.

Автоматизированное тестирование, continuous integration, инструменты для удаленной отладки, скрипты для развертывания сред и образов – это сложная поначалу, но очень эффективная в последствии практика позволяет автоматизировать часть работы, избавиться от рутины, находить проблемы быстро и на начальных этапах. Многие компании уже оценили важность автоматизации, открывая соответствующие вакансии и готовя собственные кадры по автоматизации.

Начали делать новый проект для одного достоточно крупного заказчика. Нужно было настроить сервер для CI, тестирования и развернуть систему контроля версий. Всё бы ничего, но сервера у нас не было. Было написано письмо начальству с просьбой предоставить сервер (или хотя бы обычный компьютер). Через две недели еще одно письмо, через месяц — еще одно. Обратка приходила в стиле “а зачем вам сервер?”. Через два месяца, когда переписка превратилась в теоретическое обсуждение необходимости аппаратного и программного обеспечения в ИТ компании, был найден какой-то старенький полурабочий комп, который и стал тем сервером. Хотя, как вы могли уже догадаться, даже инициатива “снизу” не спасла этот проект от провала.

И да, инструменты должны соответствовать уровню вашей компании. Управлять сотней человек и двадцатью проектами с помощью Гугл Докс можно, но сложно. С другой стороны, устанавливать Шарепойнт, если у вас работает 5 человек тоже не комильфо. Всегда нужно дружить с головой и реальностью.

Экспертиза

В наше время уникальной экспетизой может быть редкая, специализированная или новая технология (Tizen, Xamarin, Unity, AutoCAD), доменная область (разработка мобильных приложений для банков) или специализация (ускорение работы WordPress, автоматизация UI тестов). Знание конкретного мейнстримного языка, технологии или CMS не может являться конкурентным преимуществом.

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

Ремоут

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

Как часто вам приходилось искать сотрудников? Хорошо, если вы международная корпорация а-ля Майкрософт или Гугл, или вы находитесь в больших городах – Киеве, Сан-Франциско или Лондоне. А если вы живете в небольшом городе, и имеете узкую специализацию? В таком случае единственное правильное решение – работать с удаленными людьми. Я специально не говорю с «фрилансерами», потому что «удаленный сотрудник» и «фрилансер» – это разные люди.

Вы переживаете, что сотрудник будет филонить? Переживаете, что будет дописывать часы? У меня для вас плохая новость: вы просто не умеете адекватно оценивать объем работ и трудозатраты. Правда такова, что сотрудник, который поставит за цель ничего не делать, будет филонить хоть удаленно, хоть у вас под боком в равной степени.

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

В общем, покупаем книгу Ремоут, читаем, перестаем беспокоиться и начинаем жить.

Коммуникация

Пожалуй, самый простой и самый сложный пункт одновременно.

С одной стороны, недостаток коммуникации – плохо, с другой – много коммуникаций тоже не помогает. Я уже молчу о бесконечных митингах, переписках на 25 человек и других прелестях «общения».

Как говорят, не знаешь, чем заняться, делай митинг.

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

А вот это знакомо? Заполни, пожалуйста, часы в системе учета времени, потом часы, потраченные на задачи в системе управления проектами, обнови документацию и гант чарт, вечером пришли ежедневный отчет, а потом в 10:00 все таки расскажи всем, что же ты, друг мой, вчера сделал и чем ты будешь заниматься сегодня между заполнением отчетов и митингами.

Кодекс самурая

Есть несколько правил и рекомендаций, как должны выглядеть взаимоотношения с вашими заказчиками, а также внутри самой компании:

1. У каждого рядового сотрудника должно быть не больше двух начальников, а задачи и время их выполнения не должны противоречить друг другу. В противном случае сотрудник будет вынужден самостоятельно определять приоритет задач, что он, с большой долей вероятности, будет делать не верно из-за отсутствия всей необходимой информации и знаний.
2. На любом проекте каждый член команды должен знать свою роль (или список ролей), а также роль каждого человека со стороны заказчика. Иными словами, каждый член команды должен знать, у кого право финального решения, кто будет принимать проект, чьи распоряжения имеют рекомендательный, а чьи — обязательный характер.
3. Для каждого типа проекта необходимо иметь список заготовленных вопросов, чтобы с самого начала на высоком уровне очертить ТЗ. Для мобильного приложения этот список может иметь такой вид: 1) какие платформы и их минимальные версии нужно поддерживать 2) есть ли уже готовое API и если нет, то когда будет готово 3) будет ли компания-исполнитель принимать участие в публикации/поддержке приложения и т.д.
4. Четкость и детализация ТЗ должна зависеть от четкости и адекватности заказчика. Если заказчик четко знает, что ему нужно, то ТЗ может быть минимальным. Если же заказчик плавает и часто меняет свои решения — ТЗ должно быть максимально подробным. Отношение к новым заказчикам должно быть более критичное, чем к текущим, а самый лучший способ протестировать адекватность и быстроту принимаемых решений — получить предоплату. Именно на этом этапе вы тестируете весь процесс работы, но в миниатюре. И если есть сложности на этом этапе — значит, не миновать сложностей и в будущем.
5. Закон Мерфи, надеюсь все знают :-) Есть еще парочка, о которых не помешало бы помнить. 1) Закон Паркинсона 1: работа заполняет время, отпущенное на неё. Так, согласно Паркинсону, если команда может писать проект год, то она и будет писать его год. 2) Закон Парето (или принцип Парето): 20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата. 3) в случае переоценки бюджета и сроков проекта цена ошибки будет расти линейно, а в случае недооценке — по экспоненте. 4) 9 женщин не могут за месяц родить ребенка, а максимальный предел сжатия сроков — не более 25%. Дальше — только овертаймы и снижение общей эффективности.

Итоги

Результат вас удивит: в зависимости от эффективности процессов, продуктовность одного и того же человека может меняться в 2-5 раз. Именно поэтому небольшие компании всегда более эффективны, чем корпорации или большие бодишопы. Именно эффективность процессов позволяет сделать проект в 2-3 раза быстрее, чем конкуренты. Именно поэтому стоимость часа «эффективного» сотрудника выше, чем у бодишопов, но итоговая цена проекта всегда будет ниже.

Автор: Chebanov

Источник ^[1]