[Перевод] Четыре ошибки программистов, которые я осознал, только когда стал CTO
Я работал программистом более пяти лет. Не особо впечатляет, ведь кто-то из вас, вероятно, имеет в три раза больший опыт, но мне нравилось думать о себе как о сениор-разработчике. Звучит серьёзно и солидно, правда?
Однажды мне предложили стать Chief Technology Officer (CTO) в медтех-стартапе. Поработав некоторое время на этой новой должности, я могу обернуться назад и сказать, что не был сениор-разработчиком. Не поймите меня неправильно — я по-прежнему считаю, что обладаю отличными знаниями программирования, особенно веб-разработки;, но если это так, почему я не думаю, что был сениором?
Всё это из-за четырёх заблуждений, которые у меня были.
Пользователь (?)
Нет, он не идиот.
Да, пользователи работают с приложением неожиданными, часто странными способами.
Да, пользователи могут задавать вопросы, которые кажутся по-настоящему глупыми.
Да, иногда пользователи просят добавить функции, которые кажутся бессмысленными.
Да, пользователи испытывают трудности с функциями, которые кажутся понятными сами по себе.
Пользователь — не специалист. Мой врач не требует от меня, чтобы я знал отличия между липопротеинами низкой и высокой плотности. Так почему я привык предполагать, что пользователь знает, каким браузером он пользуется? Это очевидно вам и мне, но моя мама считает, что Google и Интернет — это синонимы. Она бы сказала, что не пользуется никаким браузером, потому что использует Google.
Иногда чтобы удовлетворить пользователя мне нужно было переопределять части фреймворков для изменения их стандартного поведения. Иногда мне приходилось добавлять поддержку браузеров, которые я поддерживать не хотел (привет, пользователи Safari). Сегодня это кажется мне глупым, но в то время я действительно думал, что если мне приходится создавать в своём коде обходные пути для удовлетворения требованиям клиента, то в этом виноват клиент.
Выбираем самое лучшее имя для переменной.
Чистый код, юнит-тесты, отличная документация — это, без сомнения, важно. Я как программист всегда стремился писать чистый код с использованием современных паттернов, часто проверял актуальность всех зависимостей в проекте и т.п. Я хотел быть Хорошим Программистом.
Когда мой менеджер по продукту попросил отказаться от юнит-тестов, чтобы увеличить скорость разработки, я испытал гнев — разве он не понимает, насколько важны юнит-тесты? У нас не было никакого автоматизированного тестирования, поэтому юнит-тесты оставались единственной надеждой на обеспечение стабильности и отсутствие регрессий в продукте.
Это решение показалось мне недальновидным. Кроме того, он рекомендовал перестать писать документацию и преобразовать код в менее сложную архитектуру (мы могли это сделать, потому что находились в самом начале проекта).
Да, я согласился, что это в какой-то степени ускорит разработку, но был уверен, что это грозит кучей проблем в будущем. Мы потратим кучу времени на устранение регрессионных ошибок, а новая архитектура окажется слишком простой, когда масштаб проекта начнёт расти! И как мы будем знакомить новых программистов с проектом без хорошего readme?
Мы часами обсуждали то, насколько плохо это решение, и сколько оно будет стоить нам в будущем.
Этот проект завершился провалом спустя несколько месяцев, потому что значительно превысил бюджет.
Годы спустя я вынужден признать правду: наша команда совершила огромную ошибку. Мы думали о будущем и позабыли о настоящем. Мы совершенно игнорировали обстоятельства — ограниченный бюджет и необходимость создания MVP за короткое время.
Разумеется, замечательно писать код, который ты можешь показывать другим и гордиться. Но ещё лучше успешно завершать проекты. В конце концов, программирование — это не искусство.
Отношение моей старой команды к пробованию чего-то нового.
В моей предыдущей компании мы создавали каждый проект с одинаковым технологическим стеком: Symfony и Angular. Почему? Является ли Symfony лучшим бэкенд-фреймворком? Нет. Может быть, Angular — единственный способ создания современного фронтенда? Нет. Мы всегда выбирали эту связку технологий, потому что не знали другие так же хорошо, как эти. Это была наша зона комфорта, но действительно ли неправильно выбирать хорошо известные технологии для новых проектов? Это зависит от разных факторов.
Во многих случаях ваш следующий проект будет более-менее похож на предыдущие. Было бы нелогично тратить много времени на изучение новой технологии, потому что у вас уже есть проверенные решения. Но иногда такой выбор будет ошибочным.
Помню проект, в котором самым важным требованием был хорошо работающий WebSocket. Что мы выбрали для создания бэкенда? Symfony, разумеется. Возможно, сегодня реализация WS на PHP будет выглядеть проще, но в то время это было кошмаром. Мы потратили много времени, чтобы заставить его работать. ОЧЕНЬ много. Мы знали, сколько времени (и денег) будет потрачено для создания WS на PHP, но мы отказались от идеи использования Node. Почему? Не могу сказать точно. На Node мы бы создали API в десять раз быстрее, но он не был в технологическом стеке нашей команды.
Я очень счастлив, что программисты в моей нынешней команде более открыты всему новому, чем был я. На прошлой неделе мы решили полностью заменить технологию, используемую для создания части нашей системы. Я уверен, что это решение сэкономит нам много времени, даже если придётся что-то учить с нуля.
Что я думал о решениях менеджера по продукту.
Когда я работал программистом, мои отношения с менеджером по продукту были… натянутыми. Каждый раз когда он говорил мне о новых изменениях в содержании задачи, я думал: «Почему ты не можешь сразу сделать свою работу и определиться с задачей до того, как я начну работать? Разве так сложно решить заранее, как должна работать фича?»
Это было так наивно, но я действительно считал, что всё так просто. Теперь я полностью понимаю, как сложно спланировать каждую деталь проекта. Нужно учитывать ограничения технологий и бюджета (что на самом деле одно и то же), необходимо думать о пользователях, которые будут работать с твоим продуктом, нельзя забывать о требованиях бизнеса и маркетинга. Иногда некоторые требования неизвестны в начале; иногда меняются обстоятельства у бизнеса, а иногда нужно сначала что-то создать, чтобы понять, что это можно сделать лучше.
Ещё один аспект — менеджеры по продукту могут совершать ошибки. Да, всё так просто. Программисты создают баги и PM тоже. Сегодня это кажется мне настолько очевидным. Если бы я был программистом получше, то понял бы это раньше. Вместо того, чтобы пытаться доказать, насколько он ошибается, мне нужно было сосредоточиться на поиске решений.
Это иронично и печально, но в какой-то момент я забыл, что у меня и менеджера одна цель — создание отличного продукта. Просто у него гораздо больше знаний о бюджете, обстоятельствах у бизнеса, требованиях со стороны клиента, дедлайнах и приоритетах. Именно поэтому я не понимал некоторые его решения.
Для кого-то из вас эти четыре пункта могут оказаться очевидными. Если вы работаете в отличной организованной agile-команде с хорошим руководителем и не забываете основные правила UX, то я искренне рад за вас. Наверно, вы можете быть гораздо лучшим программистом, чем был я. Ведь чтобы «быть хорошим программистом», недостаточно только технических навыков. Гораздо важнее понимать, какую ценность ты можешь принести компании, и как это сделать. Теперь я понимаю определение сениор-разработчика следующим образом:
Сениор-разработчик — это не тот, кто понимает каждый аспект технологии. Это человек, который поможет вашей компании создать качественный продукт, даже если это потребует от него выхода из зоны комфорта. Решения важнее, чем проблемы.
На правах рекламы
Подыскиваете VDS для отладки проектов, сервер для разработки и размещения? Вы точно наш клиент :) Посуточная тарификация серверов самых различных конфигураций, антиDDoS и лицензии Windows уже включены в стоимость.
