Рубрика «управление разработкой» - 44

Пользовательское интервью внутренними силами компании: через ошибки к открытиям - 1

Привет, я Саша, скрам-мастер из Туту.ру в команде туров. Не так давно мы проводили пользовательское интервью для нашей новой фичи — Джарвела. Хочу поделиться с вами ошибками и открытиями, которые помогли нам провести это интервью так, что оно затронуло и изменило краеугольную основу фичи. Это помогло продукту и прокачало нашу команду, надеюсь, будет полезно и интересно и для вас. Но чтобы понять суть наших открытий, вас нужно познакомить с Джарвелом и провести по нашему пути.
Читать полностью »

Привет! Я Валерий Лаптев, руководитель разработки LM в России. За два года мне нужно было поднять огромный отдел, и это был довольно интересный опыт.

Дело в том, что «Леруа Мерлен» есть во многих странах. Головная компания — во Франции, называется ADEO. Там пишут код под Францию, Италию, Испанию и Россию. Бизнес-модели у нас разные: если на российском рынке мы держим минимальные цены (ниже всех конкурентов в мониторинге), то в Европе всё иначе. На самом деле отличий море — начиная от особенностей локали и заканчивая другим законодательством. Есть особенности инфраструктуры России (те же очень большие задержки до Хабаровска) и другой жизненный цикл оформления заказа. Всё это порождает вот такой адский код, состоящий из огромных блоков IF:

Зачем нам в «Леруа Мерлен» нужен собственный российский отдел разработки на 200 человек - 1

Два года назад у нас было 60 магазинов и много-много хотелок по фичам. Накатывались они примерно за полгода и не всегда правильно. Последней каплей после кучи отклонённых по низкому приоритету фич была просьба завести в заказ поле-строку, чтобы мы его уже потом сами парсили. Это нужно было для особенностей доставки в России, поскольку страна больше других стран присутствия LM. Нам отказали и в этом, точнее, сказали, что будет где-то через семь-восемь месяцев.

Полугодовой цикл неспешной головной компании нам не подходил. Естественно, мы предложили написать свой код, отдать на ревью и подождать внедрения… Правда, из этого ничего хорошего не вышло.Читать полностью »

Привет, Хабровчане! Очень скоро пройдет юбилейная, десятая конференция DevConf. В рамках секции менеджмента эксперты поделятся своим опытом и своими знаниями в сфере управления. Представляем вашему вниманию некоторые из докладов секции:
DevConfX::Management – доклады управленцев простыми словами - 1
Страх и ненависть работы в высокотехнологичном стартапе (Константин Юревич)
Константин – менеджер, управленец, который начинал свой путь разработчиком. Человек, который может говорить с технарями на одном языке и действительно понимать причины и мотивы их слов и поступков. В рамках доклада поговорим про работу в стартапе и разберем ответы на следующие темы:
— Как опыт работы в стартапе может изменить образ мышления разработчика навсегда.
— Кто он, идеальный разработчик в стартапе?
— 5 причин, почему в первый месяц половина не выживает.
— Стоит ли попробовать сделать свой стартап.
— Open Source проект как альтернатива стартапу.

Гайд по построению карьеры в ИТ (Роман Сорока)
Одним из самых сложных вопросов для новичков в IT технологиях, является вопрос собственного развития и роста. Практически невозможно найти серебряную пулю в ответе на этот вопрос. Однако точно можно предостеречь от ошибок при построении собственной карьеры. Об этом мы и поговорим в рамках выступления Романа – специалиста с более чем десятилетним стажем, выросшего из инженера контроля качества до руководителя группы.

Погружение в блокчейн для веб-специалиста (Дмитрий Бородин)
Доклад от одного из прзнанных экспертов IT-сообщества, основателя социальной сети Topface, Дмитрия Бородина, посвящён раскрытию популярных мифов про блокчейн технологии. Громкий хайп улегся, а понимания, когда нужен блокчейн, а когда нет сильно больше не стало. Дмитрий расскажет о основных заблуждениях в мире данной технологии, а также даст рекомендации, которые позволят понять вам необходимость применения блокчейна.
Читать полностью »

Минус уши или как не испортить звук в игре с самого начала - 1

Статья о звуке, но адресована скорее не саунд-дизайнерам (которым всё известно), а продюсерам, ПМ-ам игровой индустрии и начинающим разработчикам. Собранные здесь ошибки — это наш собственный опыт из времён, когда War Robots была ещё прототипом в новой для компании нише.

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

Почему только прокачка кодинга не сделает из тебя лучшего разработчика - 1

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

Миф про хорошего разработчика гласит, что он:

  1. Пишет чистый код
  2. Знает много технологий
  3. Быстрее кодит задачи
  4. Знает кучу алгоритмов и шаблонов проектирования
  5. Умеет отрефакторить любой код по Clean Code
  6. Не тратит время на непрограммистские задачи
  7. 100% мастер своей любимой технологии

Так видят идеальных кандидатов HRы, и вакансии, соответственно, выглядят тоже так.

Но мой опыт говорит, что это не сильно соответствует действительности.

Читать полностью »

Кто про что, а я про баги.

В прошлом году я рассказывала вам про Багодельню — мероприятие, проводимое у нас в компании для чистки бэклога багов. Событие хорошее и полезное, но решающее проблему с багами разово. Мы провели уже шесть Багоделен, но количество участников постепенно снижалось и стало очевидно, что потребность в этом мероприятии начала отпадать. Основной причиной стало появление у нас Zero Bug Policy. О ней есть не так много источников на русском, где можно почитать и найти удобное решение для себя. В этой статье я расскажу про наш подход к теме и с удовольствием почитаю про ваш опыт в комментариях.

Zero Bug Policy. Нет багов — нет проблем? - 1

Читать полностью »

#NoDeployFriday: помогает или вредит? - 1

Нужно ли запрещать деплоить в production в определённое время? Или движение #NoDeployFriday стало реликтом времён, когда не было всеобъемлющих интеграционных тестов и непрерывного деплоймента?

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

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

Когда-то я был младшим разработчиком и ужасно не любил слово «процессы». Все эти регулярные встречи и прочее общение казались глупостями, отвлекающими от содержательной работы (написания кода, конечно). Думаю, такой этап случался в жизни у каждого, кто занимался разработкой; но такому этапу полезно повторяться регулярно: любую деятельность можно оптимизировать (например, вообще отменив), и иногда ощущение бессмысленности происходящего оказывает поистине целебное действие.

Как устроены процессы разработки в различных компаниях - 1

Мы решили посвятить процессам разработки наш следующий Team Leader Meetup, который пройдёт вечером 17 июня в московском офисе Яндекса. Регистрация открыта!

Нашими экспертами согласились быть:

  • Анатолий anatolix Орлов, CTO, Ozon
  • Алексей Катаев deusdeorum, Head of Software Development, SkyEng
  • Александр Гутман, CTO, JoomPay
  • Евгений Парамонов, руководитель разработки поисковых подмешиваний, Яндекс
  • Андрей Плахов yafinder, руководитель отдела функциональности поиска, Яндекс

Сегодня они отвечают на некоторые вопросы, чтобы подготовить будущую дискуссию:

1. На какой основе построены процессы у вас в компании?
2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой индивидуальным мастерством?
3. Бывают ли ситуации, в которых тимлид имеет полное право игнорировать любые процессы?
4. Расскажите какую-нибудь страшную историю из вашего опыта со словом «процесс»

Под катом — много огня, сарказм в адрес авторов вопросов, максимально различные мнения и, конечно, страшные истории.

Читать полностью »

Ведущий разработчик — не зря «ведущий». Эту фразу я услышал на одной из конференций по IT-менеджменту и задался вопросом, а почему «не зря»? Именно он подтолкнул меня написать эту статью.

Оценивая свой опыт я могу сказать, что основные характеристики ведущего разработчика можно свести к 3 пунктам:

  • Думает не только о своей грядке, но и обо всем огороде (это ключевое качество). Готов выстраивать стандарты и следить за их исполнением.
  • Отлично знает свой язык и фреймворк, превосходно разбирается в архитектуре, имеет солидный опыт работы за плечами. «Солидность» это не обязательно означает время проведенное за клавиатурой, важно количество и качество написанных проектов.
  • Хочет и может аргументированно доносить свое мнение, отстаивать его и искать компромисс при необходимости.

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

Одной из сильнейших его сторон является целостная картина мира, в которой совершенно точно определено, что такое хорошо и что такое плохо. Это позволяет быстро принимать решения и без колебаний воплощать их в жизнь. Эта уверенность заразительна и позволяет завоевать авторитет в глазах менеджеров, у которых уже не все так просто и понятно. Ведь кроме технических «лучше», «надежнее» и «быстрее» на уровне менеджмента появляются всякие «заказчик не захочет», «инвестор не оценит» и всевозможные «Вася обидится». Когда менеджер слышит «нет, тут нужно делать только так, потому что 1, 2 и 3» — он вздыхает с облегчением. Выбор становится очевиден и ответственность падает с его плеч.

Год назад я ушел с позиции ведущего разработчика окончательно и решил сделать небольшую ретроспективу своих самых досадных ошибок. Итак:

Ошибка номер 1. Оверменеджмент

Читать полностью »

6 способов угодить в ад готовых решений и спустить миллион-другой - 1

Привет, сейчас я расскажу тебе, что будет с перспективным проектом, если с самого начала обратиться к готовым решениям а-ля WordPress, Open Cart и любым CMS, думая, что это и есть MVP. Основываться буду на трёх-месячном опыте работы на одном из проектов, в GitHub которого за предыдущие 8 месяцев так и не упало ни одного коммита в production ветку.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js