Wallride.ru
Гонки по вертикали. Заметки о людях и управлении.
Хитрости собеседования разработчиков
2 Февраль
Ещё раз хочу поднять тему набора новых специалистов в команду разработчиков. Лучших специалистов.
Под лучшими я понимаю опытных, инициативных, способных самостоятельно без пинков решать любые задачи. Обнаруживать проблемы и устранять их.
По моему опыту и опыту моих коллег работодатель часто ограничивается проверкой знания теории. Например, были случаи, когда кандидату сразу отказывали, если он с ходу не мог вспомнить какую-то определённую команду. На мой взгляд, гораздо важнее оценить, насколько человек способен думать (как самостоятельно, так и в группе), принимать решения и аргументировать их. Для оценки этих качеств я использую следующие нехитрые приёмы…
Дисциплина и наказания
17 Январь
Речь пойдёт о том, как поддержать бороться с опозданиями в трудовом коллективе.
Я встречал много попыток борьбы с опозданиями в разных компаниях. Одни боссы жёстко отчитывали, другие жестоко штрафовали, третьи заставляли писать объяснительные. Однако все эти репрессии не давали и никогда не дадут положительного результата. Они разрушают отношения между начальником и подчинёнными, демотивируют, заставляют людей обманывать систему.
В моей команде, в принципе, свободный график (работай когда удобно, лишь бы работа выполнялась), и народ подтягивается на работу начиная с 9 утра и заканчивая часом дня. Уходят, соответственно, в 7-10 вечера. Однако чтобы блюсти дисциплину и не распускать это ещё дальше, ввели правило: каждый, кто приходит после 11:30, приносит килограмм мандаринов/бананов/яблок. Да, опаздывать меньше никто не будет, но зато убили кучу зайцев:
- обозначили максимально-приемлемое время прихода (критерий оценки дисциплины) или, другими словами, договорились, «что такое хорошо и что такое плохо»;
- польза для всей команды от опоздавших – все едят витамины
- снят стресс с опоздавших. Они будут меньше переживать на счёт своей задержки, поскольку точно знают, что на начальник не будет срываться на них и устраивать истерики. Всё ограничится фруктами.
Расширять свою команду или дать проект на аутсорс?
12 Январь
После освежения в памяти книги Тома Демарко «Deadline» сели моделировать такие кейсы. У нас есть 5 программистов и несколько проектов, которые нужно сделать срочно. Своими силами не успеваем, что же делать – набирать новых или отдать избыточную работу на аутсорс?
Исходные данные
Имеем сработавшуюся команду из 5 разработчиков.
Моделируем два кейса:
- набираем 3 новых разработчиков к себе в штат;
- связываемся с внештатной командой из 3 человек.
В обоих случаях оцениваем прирост в стоимости и производительности через полгода и год.
Мечты и цели
5 Декабрь
Открыл для себя «Америку» в рамках обсуждения того, как люди формулируют для себя мечты и ставят цели, а также что их движет к достижению этих целей.
Наблюдение №1: Люди очень редко движутся к своим мечам. Им бы хотелось в принципе эмигрировать в другую страну, совершить кругосветное путешествие, купить загородный дом или феррари. Или, скажем, открыть приют для бездомных собак. Но эти мечты остаются без малейшего движения к ним. Мечты очень редко движут людьми. Впрочем, на то они и мечты.
Наблюдение №2: Люди ставят для себя цели не для того, чтобы чего-то достичь, а для того чтобы УБЕРЕЧЬ себя от каких-то угроз. Это оказалось наиболее интересным «открытием» с точки зрения управления и мотивации. В отличии от мечты, цель предполагает совершение определённых действий в заданном направлении. Люди оценивают цели, декомпозируют и постепенно достигают. Всё выглядит очень круто и здраво. Но когда спрашиваешь, какие именно цели люди перед собой ставят и ПОЧЕМУ, то картина преображается. Мотивом целей чаще всего является избегание угроз, сохранение своей зоны комфорта, и все они как правило далеки от мечт. Например:
- Вася планирует построить дом и переехать жить со своей семьёй. Мотив: городская квартира с достаточной площадью для проживание семьи из 5 человек и пары собак стоит гораздо дороже загородного дома. Цена такой квартиры неподъёмна, а в маленькой квартире все они уже не помещаются.
- Юля учится в институте, и на данный момент у неё цель – написать курсовую работу. Мотив: без неё Юлю выгонят из института.
- В крупной компании ведущий программист Григорий обозначил цель – обеспечить отказоустойчивость системы. Мотив: чтобы меньше попадало от начальства, когда система не выдерживает нагрузки.
В общем, примеров, если покопаться, каждый может найти вокруг предостаточно. Но есть и другие, более обнадёживающие. У моего знакомого была мечта совершить кругосветное путешествие. И он превратил её в цель. Просчитал, составил план, подготовился, обзавёлся знакомствами по всему миру. Потом уволился с поста топ-менеджера в крупной компании и отправился в путь. Сейчас он объехал уже более половины земного шара с рюкзаком за плечами, и это сделало его счастливым.
А о чём мечтаете Вы? И соответствуют ли ваши цели мечтам?
Женщины-программисты
19 Ноябрь
У технарей десятилетиями формировался жёсткий шовинизм в отношении девушек, выбравших работу в сфере IT. Особенно если дело касается разработки ПО. Любой мужчина-разработчик фыркнет: «Женщина-программист??! Нонсенс!». Убеждения большинства мужчин варьируются от «они не умеют мыслить логически» до «их место у плиты».
Между тем у меня нет предубеждений на счёт совместимости прекрасного пола и технических профессий. Даже наоборот, по моему опыту женщины программисты работают лучше мужчин. И вот как это проявляется:
- Во-первых, мужчин-программистов на порядки больше, чем женщин. Но если брать отношение достойных работников к количеству бездарностей и лоботрясов, то мужчины проигрывают!
- Мужчины в силу своего мужского начала зачастую преисполнены неоправданными амбициями и завышенной самооценкой. Сильно проявляется фактор соперничества на профессиональном поле. От этого возникают бестолковые споры, «холивары», делёж сферы влияния… Битва за территорию, другими словами.
У женщин другое поведение от природы. Они не так часто проецируют свои амбиции на профессиональную сферу. - Женщины не так капризны, как мужчины. Да-да! Именно так! Я встречал многих мужчин-нытиков, которых постоянно что-то не устраивает: рутинные задачи, недостаточно высокий оклад, недостаточное количество развлечений, выбранные технологии и т.д. А женщинам зачастую бывает достаточно похвалы, признания её успехов, банального внимания, чтобы они чувствовали себя в работе просто замечательно.
- Вы не поверите, но женщины, с которыми я работал – ПРОДУКТИВНЕЕ! Вот прямо сейчас одна барышня закрывает вдвое больше задач (по трудозатратам), чем самый производительный мужик в той же команде.
Вы спросите – а как же качество кода? На это я скажу, что надо лучше отбирать кандидатов! И ещё: большая часть «говнокода» написана именно мужиками
Две беды интернет-стартапов
15 Ноябрь
За последние несколько месяцев я много раз натыкался на одну и ту же мысль, почему в интернете так много бестолковых сервисов или толковых, но которыми невозможно пользоваться.
Для себя я выявил две причины, почему так происходит:
- Разработчики делают проекты ради разработки.
Есть множество интересных проектов, которые никогда не смогут стать бизнесом. Как правило всё начинается со слов «а давайте сделаем социальную сеть!» и заканчивается примерно так «ну и что с того, что никто не пользуется, зато мы сделали это!». Распространённый случай, детально его описывать не буду. - Разработчики делают проекты для IT-шников
Программисты делают крутое SaaS приложение с перспективной бизнес-моделью. Оно должно стать лучшим на рынке, предлагать массу возможностей, быть гибким и способным удовлетворить любого клиента. И ещё оно должно быть реализовано по последнему слову технологической моды. А проваливается такое чудо-приложение на том, что основная масса целевых пользователей не может в нём разобраться. Парадигмы, предлагаемые модными тенденциями, не близки людям, которые работают с компьютером на уровне «почта-ворд-пасьянс». Они не знают, что такое микроблоггинг или параметрический поиск или интерфейс настройки типа «Wizard». Приложение может и решает проблемы потребителя, но каким-то непривычным и очень «странным» путём, который понятен только искушённым интернет-пользователям.
В общем получается, что хотели сделать приложение для своей аудитории, а сделали – для конкурентов (чтобы показать им, «какие мы крутые»).
Подводя итог, хочу всем рекомендовать – как можно больше времени потратить на изучение привычек и образа жизни потенциальных клиентов. Как они работают с бумажными документами, как они организуют своё время. Эта информация позволит выявить наиболее важные особенности проектируемого приложения и сделать его максимально удобным для «неподготовленного» пользователя. А это уже половина успеха!
Несколько слов о руководстве подчинёнными
19 Октябрь
В своё время, руководство людьми мне давалось довольно туго. Было много ошибок и неприятных историй. Не смотря на обилие прочитанной литературы, на практике получалось не очень.
Сегодня я вижу, что справился с большей частью проблем и расскажу, что мне помогло.
Как выбирать разработчиков для стартапа
16 Октябрь
С июля этого года я набираю разработчиков в наш стартап-проект. Вот уже три месяца я провожу не менее четырёх собеседований в неделю. И пока я включил в команду всего трёх человек. Почему так мало? Причины две: мне не нужна раздутая команда и я выбираю только лучших!
А теперь мне бы хотелось поделиться своим опытом: кто такие эти «лучшие» и как их искать.
Agile и гибкие методологии
14 Октябрь
Начнём с того, что я – руководитель интернет проектов по части разработки. Всем привет! Хочу поделиться с коллегами наработанным опытом в области построения процесса разработки и в частности в области применения гибких методологий. Про них много умного написано в интернете и армия евангелистов постоянно проводит доклады на конференциях, организует всевозможные семинары (спросите Google). Сильно вдаваться в теорию не буду, а расскажу про свой реальный опыт применения.
Пару лет назад я столкнулся с принципами Agile в относительно крупной разработческой компании. Там декларировались все ценности и номинально практиковались релизы, итерации, скрам-митинги, бек-логи (функциональные требования), демонстрации и т.д. Сейчас я работаю в небольшом стартапе с командой из 4-6 человек, и, опять же, используем принципы Agile.
Сначала кратко расскажу о тех практиках, которые использую и считаю эффективными:
- Бек-лог (функциональные требования). Проекты бывают большие. Очень большие. Они могут тянуться годами, а обилие функционала способно затмить небо. Как же подступиться к такой мега-задаче? Как оценить трудозатраты на разработку?
Мы дробим функционал системы на модули, компоненты, группы страниц и т.д. Для каждой компоненты составляем список функциональных требований. Причём требования должен составлять не заказчик, а менеджер от разработки, чтобы эти требования отражали бизнес-логику и были исчерпывающими для разработчиков. Все требования оценивается в условных единицах трудоёмкости, например, в человеко-днях. Таким образом весь проект покрывается списком оценённых требований, и становится приблизительно ясным масштаб «бедствия». - Релизы. Требования и компоненты группируются в этапы поставки продукта – релизы.
Я предпочитаю соотносить релизы с этапами развития продукта:
1 – Альфа-версия, опытный образец или прототип. Реализует минимально необходимый функционал, отвечающий целям проекта;
2 – Закрытая бета для внутреннего использования и тестирования
3 – Открытая бета, доступная для внешнего тестирования, отладки процессов и получения фидбека от первых клиентов;
4 - Выход в коммерческую эксплуатацию;
5 и далее – развитие продукта. - Итерации. Я предпочитаю недельные итерации, поскольку за неделю бывает реализовано довольно много нового функционала, требующего обсуждения на демонстрациях.
- Демонстрации. Это очень важный момент в гибких методологиях. Особенность этого мероприятия в том, что заказчик постоянно видит результат работы команды, а команда имеет возможность получать обратную связь – что было сделано хорошо, а что нужно переделать.
Как правило в ходе этих демонстраций всплывают ошибочные требования, и в режиме мозгового штурма приходят более удачные идеи, чем те, которые планировались в самом начале проекта. Таким образом бек-лог пополняется свежими требованиями, основанными не на предположениях, а на реальном опыте использования ПО. - Ретроспективы. В каждой ключевой точке проекта (планирование итерации, демонстрация, релиз) необходимо проводить разбор полётов. Редко когда разработка идёт гладко и все сроки соблюдаются. Так или иначе возникают ошибки, всевозможные проволочки и бестолковая трата времени. И именно регулярное проведение ретроспектив позволяет анализировать ход работы в предыдущем периоде, выявлять проблемы и своевременно их устранять. Важно не превращать этот процесс в порку подчинённых. Разработчики сами должны выявлять факторы, мешающие их работе. А я как руководитель должен устранить эти факторы со всеми своими административными полномочиями.
- Ежедневные летучки (SCRUM-meetings). Каждое утро команда разработчиков собирается вокруг доски с задачами и каждый обозначает, что было сделано вчера, что будет сделано сегодня, какие есть вопросы и проблемы. Регламент – 15 минут, стоя. Такие короткие митинги позволяют разработчикам постоянно быть в курсе событий, кто чем занимается и получить дельные советы. Ну а у руководителя, таким образом, всё под контролем!
Это тот набор инструментов из арсенала Agile, которыми я пользуюсь. Разумеется, эти практики не могут подойти абсолютно всем ввиду ряда причин, о которых ниже. Сейчас гибкие методологии у меня применяются в небольшой команде и работают из рук вон хорошо! Разработка продукта прозрачна для заказчика. Он всегда видит результат и может своевременно внести коррективы.
Однако в крупной компании все они фатально не работали в 90% случаев! И вот какие факторы препятствовали:
- Внешние заказчики диктовали одновременно сроки и объём работ. Подозреваю, что бюджет тоже. Это были очень крупные и несговорчивые заказчики, имя которых все знают, но я не назову
- Менеджеры продуктов оказывали на разработчиков давление по всем фронтам, используя всю иерархию оргструктуры. В сущности, они не были частью команды, поскольку преследовали другие цели (собственные бизнес-задачи и «прикрыть свой зад»)
- Проектов было очень много, от чего фокус внимания у команды рассеивался. Сложно сконцентрировать внимание и творческий потенциал на разработке нового проекта, когда 50% времени тратится на рутину в виде поддержки старого барахла.
- Бюрократия и неработающие регламенты. Говорит само за себя.
Такие условия подобно напалму уничтожают почву для открытого обсуждения, новаторства, творчества и производства высококачественных продуктов с удовольствием от работы. Ценность под названием «прикрыть свой зад» начинает доминировать.
В таких условиях гораздо лучше подходит вариант детального планирования в MS Project с указанием всех зависимостей. Процесс разработки нужно максимально автоматизировать, а проекты - унифицировать, то есть привести всё к конвейерной сборке, предсказуемой и безрисковой.
Не смотря на негативный и даже провальный опыт внедрения Agile, перечисленный набор практик в любом случае очень полезен и в большинстве случаев жизнеспособен. Причём не только в кругах разработчиков, но и во всех смежных областях с разработкой ПО. Важно выбирать с умом те практики, которые БУДУТ эффективны в Вашей компании. По крайней мере они будут полезны Вам как руководителю и Вашей команде, поскольку эти практики способствуют поддержанию тонуса и здоровых отношений.
А используете ли Вы Agile и с каким успехом?