Бюро Цифровых Технологий

Манифест

Принципы, на которых строится заказная разработка в Бюро Цифровых Технологий.

§1

Искусство заказной разработки

Пошел ровно 15-ый год того как я нахожусь в профессии. Начинал я в ВУЗ-е программистом на паскале, рисовал текстуры для openGL, потом познавал c#, objective-c, swift, Node.js. Мне довелось работать как со стороны клиентов, так и исполнителей. Всё это дало мне понимание того, как запускать ит-проекты.

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

При этом многие программисты называют процесс программирования - искусством. В этом я с ними согласен, ведь без образования, равно как и современное искусство, код не понять. Тем более, если код писал джуниор.

Есть такая цитата:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

И это подводит к той мысли, что на самом деле весь процесс заказной разработки - своего рода искусство. Оно проявляется как в визуальной составляющей от дизайнера, функциональной части программиста и тестировщика, а также умении всё это соединить воедино, собрать и отдать клиенту проектным менеджером.

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

§2

Как устроен Интернет

Я люблю задавать вопрос на интервью следующего характера:

Расскажите как устроен интернет.

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

Мне как-то написал клиент:

Как понять, при каких размерах базы конкретного заведения скорость загрузки начнет раздражать пользователя?

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

Скорость работы мобильного приложения не зависит от размера базы;
Скорость загрузки начнет раздражать после того, как в базе будет 10 000 собак;
Скорость загрузки зависит от количества обращений в базу. База может хранить миллионы записей, минимальная инфраструктура будет стоить 300 рублей и выдержит 50 запросов в секунду, что примерно1к пользователей в месяц.;
Скорость загрузки приложения зависит от того, как сделано приложение, как правильно кешируются запросы на фронте и на сервере, а также какая серверная инфраструктура поддерживает администраторскую панель.

Я уверен, что при желании можно найти еще массу других вариантов ответить на данный вопрос. Если дать этот вопрос дизайнеру, он вообще начнет думать об UX составляющей. Но важно другое, любой исполнитель понимает, что иногда самый простой ответ гораздо лучше, чем грузить лишней информацией, просто потому, что для клиента база прямо в приложении, он может не знать принципов REST-архитектуры. А объяснять просто, мы в силу специфику не умеем.

И вот так мы берем и упрощаем ответ на один вопрос, потом на другой, и у клиента возникает ощущение, что все довольно просто, и он прекрасно понимает, как все устроено. В прекрасное мгновение, возникает противоречивая ситуация, и исполнитель решает вываливать всю подноготную! К сожалению, в такой ситуации убедить клиента о его неверном представлении вряд ли получится. Да и кто прав?

А ответ простой, учиться объяснять сложные вещи простым языком и приводить цифры. В цифрах все хорошо разбираются. Только не обсуждайте объемы траффика или кол-во запросов! Я бы выбрал сценарий №3 из приведенного выше. Он дает клиенту пищу для размышлений и дает нам общее основание для дальнейшего обсуждения. Цените свое время и время клиента.

§3

Как Python-разработчик превращается в инженера-программиста

Все мы встречали такие наименования в трудовых, как «Инженеры-программисты», «Специалисты V категории» и прочие инженерно-специфичные заголовки. Многие разработчики недоумевают, почему на hh.ru указана позиция условного iOS-разработчика, а при трудоустройстве название резко меняется. Тому есть несколько причин, и чтобы разобраться, мы должны понять, как появляется данная позиция.

Чаще всего такие названия встречаются в госкорпорациях и крупном бизнесе с численностью сотрудников более 500 человек. Здесь существует система грейдов, в соответствии с которой назначается заработная плата. Если бы их не было, то мотивация зависела бы от людей и их личных предпочтений, а этому выделяется крайне малый кусок. В связи со спецификой компании в ней уже заведены позиции инженеров.

Например, есть инженер 2-го разряда на нефтеперерабатывающем заводе (НПЗ), который меняет механизмы. Тут в компании возникает запрос завести позицию Python-разработчика. Это вызывает ступор, поскольку планки по зарплатам и обязанностям уже заведены — например, инженер мог получать 100 тысяч рублей при 2-м разряде. Естественно, в условиях конкуренции людей так не набрать.

Возникает дилемма — менять процессы или искать людей. На изменение процесса уйдет до полугода. Выкручиваются следующим образом: трудоустраивают людей в дочернее юридическое лицо, где те же грейды, но планка зарплат другая. Или ещё вариант: заводить должности и «одалживать людей» в другое юридическое лицо. Такой вот получается субподряд — органически формируется дочерняя компания, которая обслуживает хотелки основной.

А на выходе как результат: человека устроили, а процессы не подстроили. Отсутствие адаптации, HR бренда компании и тому подобное. Через какое-то время большой бизнес решается на цифровую трансформацию, но до этого должно пройти некоторое время и накопиться еще с десяток других проблем. А Python-разработчик из middle все так же остается инженером 2-го разряда.

§4

Почему господряды передают друзьям и родственникам

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

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

Естественно, у этого есть обратная сторона в виде лишней траты ресурсов, потому что запредельным доверием начинают пользоваться в том числе и в собственных интересах. Конечно, это не касается проектов, в которых трудится до 20-25 человек, такая история вполне управляема. Но когда в команде больше 50 человек, это приобретает совершенно другие масштабы.

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

§5

Сначала дистрибуция, затем продукт

Идеи не рождаются в вакууме. В крупных компаниях есть подход, который называется «гэмба». Он заключается в том, что всех сотрудников направляют на точку (например, АЗС), чтобы проникнуться делом, которым занимается компания. Это нужно для того, чтобы офисные работники понимали проблемы рабочих на АЗС. Впоследствии это помогает отбрасывать ненужные идеи и прорабатывать только те, которые касаются болей клиента. Всё потому, что новые идеи возникают на стыке нескольких областей.

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

Реальная ситуация: в небольшом городе располагался хоккейный клуб, у него была своя фан-база, которую нужно было увеличить. Вместо того чтобы делать IT-инструменты, клуб начал проводить мероприятия по стране под своим брендом. Казалось бы, как это может помочь? Очень просто — приходили родители с детьми и гоняли шайбу, постоянно видели логотип клуба и отношение к клиенту. Им выдавали напрокат коньки и клюшки по низкой цене, заботились о чистоте раздевалки и качестве льда. Через год фан-база выросла в 20 раз.

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

§6

Как выбирают язык программирования в бизнесе

В мире разработки существует много языков программирования, их количество постоянно растет. Для веба кто-то применяет более надежные и проверенные временем — java, C#, php. Современные разработчики уже вовсю пробуют использовать Go и даже Flutter для web. Среди мобильных есть свои языки. Выбор конкретного языка всё так же зависит от специфики задачи, но при этом и от предпочтений разработчика. Как понять, какой технологический стек выбрать?

Для себя я выработал следующую методологию, состоящую из нескольких вопросов:

Какая ожидаемая нагрузка в пользователях: до 10к юзеров, до 100к и выше?
Какой тип проекта: Стартап или Проект на развитие?
Сколько модулей в системе: до 5, до 15 или больше?
Какие ИТ-компетенции развиты в компании?
На каком стеке выполнены другие ИТ-проекты компании?

Эти вопросы помогут определиться с архитектурой, инфраструктурой, стратегией и, следовательно, технологическим стеком.

Я как-то проводил аудит по IT системы, написанной на C# asp.net. В штате не было ни одного разработчика на данном стеке, более того, в городе на тот момент насчитывались не больше 10 вакансий на этот стек, то есть не было спроса. Вопросы с поддержкой такого проекта вызывали тихое недоумение. Пришлось часть с C# сжимать в отдельный модуль, выносить его на поддержку вне штата, а основной стек делать на том, что смогут поддерживать внутри компании.