Часто я получаю запросы, в основном через linkedIn, от людей, которые спрашивают меня, как я создавал ИТ-организации, работая на разных должностях в разных компаниях.
Я также заметил, что многие стартапы, а также существующие предприятия изо всех сил пытаются нанять подходящих людей для своего ИТ-отдела. Эта проблема касается не только технологических компаний, но касается всех отраслей.
В этой статье я представляю свое личное мнение, основанное на долгом опыте работы в качестве главного архитектора, технического директора, ИТ-директора, директора по безопасности и многих других O. Вы не обязаны со мной соглашаться, но, пожалуйста, продолжайте читать, возможно, вы узнаете что-то, что поможет вам в будущем.
Типичный стартап
Многие стартапы создаются людьми с бизнес-идеей, которая, по их мнению, может изменить мир. Иногда у основателя есть опыт работы в ИТ, а чаще нет.
Типичный подход заключается в том, что основатель начинает поиск соучредителя с опытом работы в сфере ИТ, который будет выполнять функции технического директора (CTO) компании.
Многим основателям от 20 до 30 лет, и их соучредители (CTO) также находятся в том же возрастном диапазоне, что круто, но также приводит к тому, что после окончания учебы руководство компании имеет ограниченный опыт ведения бизнеса.
Основная задача технического директора в стартапе — создать минимально жизнеспособный продукт, он же MVP.
На основе опыта, знаний и личных предпочтений технического директора выбирается язык программирования, программные платформы и инструменты, где основным драйвером является то, что я знаю и могу использовать, чтобы начать немедленно и сделать это быстро.
Когда начинается процесс найма сотрудников в ИТ-отдел, критерии поиска почти всегда будут включать знание языка программирования и выбранных инструментов.
Что в названии роли?
Я ежедневно вижу списки вакансий, размещенные на сайтах, где компании нанимают разработчиков программного обеспечения, инженеров-программистов, фронтенд-разработчиков, бэкенд-разработчиков и разработчиков полного стека. В требованиях вы увидите такие вещи, как PHP, Java, Vue.js и т. д., и т. д. Это все навыки, которым можно научить людей, если они обладают нужными компетенциями.
Итак, кто такой разработчик программного обеспечения?
По моему мнению, разработчик программного обеспечения — это человек, который может писать код на определенном языке программирования для решения бизнес-задач, которые были разработаны в какой-то технической спецификации. Многие из них не имеют реального образования в области разработки программного обеспечения, такого как степень бакалавра или магистра компьютерных наук.
Они потратят много времени на Google и Stackoverflow, чтобы найти решения конкретных проблем, с которыми они никогда раньше не сталкивались.
Качество кода часто хуже, поскольку им не хватает основ разработки программного обеспечения, таких как объектная ориентация, дизайн базы данных, внедрение зависимостей, разделение задач, рефакторинг, тестирование и т. д.
Акцент в их резюме делается на языке(ах) программирования и фреймворках, с которыми они знакомы.
Вы не можете винить разработчика программного обеспечения, у него просто неправильное образование.
А кто такой инженер-программист?
Инженер-программист имеет образование в области компьютерных наук и изучил все основы, необходимые для создания сложных систем. Имея достаточный опыт, они могут разрабатывать системы, соответствующие вашим требованиям, быстро, масштабируемо, тестируемо и ремонтопригодно.
Конечно, они владеют одним или несколькими языками программирования, но благодаря своему образованию они могут адаптировать/выучить новый язык программирования за очень короткое время, поскольку разница часто заключается только в синтаксисе и структуре, а не в качестве программного обеспечения. развитый.
Как нанять правильных людей?
Процесс собеседования
В настоящее время популярно проводить техническое собеседование, спрашивая кандидата в уме, знают ли они все популярные модные словечки и стандартные вопросы.
Я никогда не проводил собеседования таким образом, поскольку фактические знания можно оценить с помощью теста на кодирование. Мои вопросы на собеседовании всегда касаются человека.
- Что делает Вас счастливым?
- Что не дает вам спать по ночам?
- Что вы ожидаете от меня как от работодателя?
Если вы чувствуете хорошие отношения с кандидатом, пришло время перейти к тесту на кодирование, если кандидат просто ищет другую работу, пожалуйста, надейтесь, что ваш конкурент наймет его.
Как насчет тестов по кодированию?
Многие компании используют тест на кодирование для оценки навыков потенциального сотрудника. Я закончил с каждым наймом, которого я сделал в прошлом (более 1000 наймов по всему миру).
Я использовал тест на кодирование по той причине, что хотел отфильтровать разработчиков программного обеспечения от инженеров-программистов, поскольку я хотел нанимать только инженеров-программистов!
Тест на кодирование — это четырех-восьмичасовой тест, который каждый может пройти в автономном режиме в любое время, но он должен отправить его в течение 24 часов после его получения. Помимо проверки знаний, я также проверял точность и последовательность. Вот некоторые требования, которые я использую в своих тестах по кодированию:
- Вам не разрешено использовать внешние фреймворки (для разработчиков iOS и Android), чтобы увидеть, понимают ли они низкоуровневые нативные сетевые протоколы, вместо того, чтобы использовать сторонний фреймворк и пробовать, пока он не заработает.
- Я предоставил строгие соглашения об именах для классов, методов и переменных, а также руководство по стилю. Если кандидат предоставил идеальное решение, но не соблюдал соглашения об именах, его не брали на работу.
- Модульные тесты для каждого класса и метода. Вы будете удивлены тем, как много людей, называющих себя инженерами-программистами, никогда не писали юнит-тестов и не разбирались в наборах тестов.
Язык программирования
Существует множество доступных языков программирования, и я работал с большинством из них за последние 35 лет. Выбор языка программирования и возможной среды, которую вы собираетесь выбрать для своей компании, очень важен и действительно зависит от того, чего вы пытаетесь достичь.
По опыту могу сказать, что язык, который использовался для создания MVP, часто не лучший язык для следующего поколения вашего продукта.
Основная цель MVP заключалась в том, чтобы как можно скорее предоставить работающую систему с ограниченной функциональностью, поэтому, как упоминалось ранее, выбор часто делается на основе собственного опыта и предпочтений технического директора.
Однако среднесрочные и долгосрочные цели различны, поэтому бизнес должен стать устойчивым. Критерии, которые вы должны учитывать при выборе языка программирования и фреймворка для следующего этапа:
- Масштабируемость → если мы вырастем до миллионов пользователей, сможем ли мы масштабироваться?
- Наличие ресурсов → могу ли я нанять инженеров-программистов в моем регионе, которые владеют этим языком.
- Проверенный → выбор проверенный? новый язык будет иметь кривую изучения, и многое не выйдет из коробки, когда вы его откроете.
- Производительность → может ли он справиться с ожидаемым трафиком/ресурсами?
База данных
Каждой системе нужна база данных для хранения информации. На протяжении десятилетий реляционная база данных была основным вариантом для выбора места хранения информации в таблицах, содержащих поля определенного типа.
Пару лет назад была представлена база данных noSQL, и я видел, как многие компании ухватились за нее просто потому, что это было круто и ново.
База данных noSQL имеет смысл во многих случаях, однако, если вы разрабатываете систему, которая обрабатывает транзакции (такие как заказы, счета-фактуры), а также предъявляет серьезные требования к отчетности, я советую использовать реляционную базу данных.
Важность проектирования модели базы данных всегда недооценивалась. За свою карьеру я работал с тысячами инженеров-программистов, но видел лишь горстку инженеров, которые действительно хороши в проектировании баз данных.
Плохой дизайн базы данных приводит к плохой производительности, плохому коду и более крутой кривой обучения для новых сотрудников.
Свобода выбора
Разрешаете ли вы своим разработчикам программного обеспечения делать собственный выбор при добавлении внешних пакетов, фреймворков, сервисов и т. д.?
В современном мире, где Agile стал методом работы, он неявно дает разработчикам программного обеспечения большую свободу.
Я настоятельно не рекомендую этого делать, так как это может поставить под угрозу ваши среднесрочные и долгосрочные цели и серьезно повлиять на ваши эксплуатационные расходы.
Недавно мне пришлось организовать ИТ-отдел компании, который предоставил свободу всем разработчикам программного обеспечения (у них не было инженеров). Во время первоначального опроса я обнаружил 6 языков программирования, 5 фреймворков, один из которых устарел на 2 года, 56 внешних сервисов и никто не понял всю экосистему.
После того, как я нанял настоящего инженера-программиста и сам запрыгнул в вагон, а также провел реорганизацию и оптимизацию, операционные расходы сократились на 1,4 млн долларов США в год всего за два месяца.
Оффшор или на месте?
Я много лет работал на месте, а также создал около дюжины оффшорных инженерных групп для различных компаний.
Основное различие между офшорным и локальным размещением заключается в физическом присутствии людей, при котором больше внимания уделяется стандартизации и общению. Еще одним отличием является стоимость, где оффшор всегда дешевле с точки зрения обналичивания, но не всегда с точки зрения возврата инвестиций.
Если оффшорная команда не управляется должным образом и не управляется по результатам, результаты могут быть неадекватными.
Я создавал оффшорные команды во Вьетнаме, Индии, Афганистане, Китае, США, Украине, Беларуси, Великобритании, Австралии и Европе с разным успехом.
Украина и Беларусь стали моими фаворитами, хорошая рабочая этика, качественные инженеры, никогда не жалуются, доступные и надежные.
Как насчет возраста?
Здорово, когда есть группа людей одного возраста. Часто в стартапах средний возраст составляет от 20 до 35 лет. Приятно иметь группу людей одного возраста, поскольку они часто находятся на одном этапе своей жизни.
Однако добавление старшего инженера в вашу команду, приносящего больше опыта, — это очень положительный момент.
Старший инженер уже сделал все ошибки в своей карьере, которые еще предстоит совершить младшей группе. Старшие будут учиться современным вещам у молодых, а молодые будут учиться у старших, чтобы развиваться с учетом производительности и оптимизации.
Свою первую коммерческую программу я написал в 15 лет на Sinclair ZX-81 с 56 КБ доступной памяти, вот и все. В настоящее время даже самое маленькое электронное устройство имеет их множество. Это заставило меня написать эффективный высокопроизводительный код, который постоянно подвергался реорганизации, чтобы уместиться в доступной памяти.
Вывод
Создание ИТ-организации включает в себя гораздо больше аспектов, о которых вы могли подумать до прочтения этой статьи. Поскольку каждый бизнес уникален, не существует стандартного подхода или решения.
Однако мой общий совет таков:
- Нанимайте только инженеров-программистов, а не разработчиков программного обеспечения!
- Нанимайте только лучших игроков.
- Не делайте свой выбор MVP стратегическим выбором на будущее только потому, что
- Не давайте слишком много свободы, но предоставьте и объясните среднесрочную и долгосрочную стратегию своим инженерам.
