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

Черновик FAQ: Почему стандарты С++ выходят каждые три года? - 1

У WG21 есть строгий график (см. P1000) выпуска стандарта каждые три года. И никаких задержек.

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

Всё это я расписал в виде вопросов и ответов для следующего черновика Р1000, и разослал копию участникам комитета, направлявшимся в Кёльн. Этот материал будет опубликован в следующей публичной версии Р1000, её мы разошлём через несколько недель начиная с текущего момента.

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

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

image

История первая. Роковые буквы

[Оригинал]

Когда-то давно Джордж устроился работать в офис Initech. Компания только что арендовала несколько этажей в старом офисном здании, недавно перешедшего из категории «городской упадок» в категорию «элегантные кофейни на первом этаже и запах крема для обуви и свежей кожаной обивки на всех остальных».

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

Его первой задачей стало устранение проблемы в Mac-версии программного обеспечения компании. В Windows она выглядела идеально, но на OSX появлялись баги рендеринга шрифтов. Подобный баг трудно найти, но Джордж, вероятно, был в прошлой жизни детективом, поэтому оказался готов к этому испытанию.

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

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

Я 18 лет в IT. Последние 10 из них руковожу: под моим подчинением в разное время были 200 человек. 

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

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

Спасение утопающих — наше дело: как бороться с демотивацией в команде - 1

С докладом на эту тему я выступал на Badoo TechLeads Meetup №4 (видео). Мой рассказ, скорее всего, не подойдёт тем, чья команда больше 100 человек: я буду рассказывать про уровень тимлида, техлида, технического директора небольшой компании. Сам я начинал с маленькой компании. Когда пришёл в команду mos.ru, у нас было три инженера. За год мы выросли до 40, за два года — до 80. Сейчас, в разное время дня и в зависимости от погоды, нас до сотни человек. 

Про них я и расскажу.
Читать полностью »

— Привет!
— Привет!
— Скажи, а каково это — делать техническую поддержку?
— Ну-у-у, представь себе велосипед… и он горит… и ты горишь… и дорога горит… и вообще, ты в аду…

(с) автор не известен

Не важно кто вы, новичок или опытный менеджер, каждый из нас сталкивался с ситуацией, когда задач много, они приходят из разных источников и конца и краю этому не видно. Еще в качестве «контрольного выстрела» кто просит все сделать еще вчера. Узнали в этом абзаце себя? Тогда данная статья вам в помощь.
Читать полностью »

Привет! Меня зовут Алёна Исакова, я ведущий тестировщик в Авито, и я хочу рассказать вам про свой опыт введения Agile-тестирования в команду. Когда я читала доступные на русском языке статьи про Agile-тестирование и ATDD, у меня сложилось впечатление, что я «не модная», «не по Agile». Казалось, что это некая сложная структура, которая требует включения разработчиков, и до её применения мне ещё «пахать и пахать».
Какое-то время я жила с этой мыслью, писала в задачи чек-лист проверок при постановке, собирала встречи «feature-team», на которую приглашались PM, QA, Frontend и Backend для обсуждения нюансов задачи до начала реализации.

Как мы внедряли Agile-testing - 1

Те, кто понимают о чем речь, уже заметили подвох, не правда ли?

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

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

В этой статье я объясню, почему тебе не нужно идеальное решение.
Читать полностью »

Docs as Code. Часть 1: автоматизируем обновление - 1

В больших проектах, состоящих из десятков и сотен взаимодействующих сервисов, всё чаще становится обязательным подход к документации как к коду — docs as code.

Я покажу, как можно применять эту философию в реалиях classified-сервиса, а точнее, начну с первого этапа её внедрения: автоматизации обновления данных в документации.

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

Жизнь доклада на TeamLead Conf идет в несколько этапов. Сначала он появляется в виде заявки, потом в программе на сайте конференции, перетекает в рассылку, в анонс на Хабр и на сцену. После — живет в расшифровке на Хабре и YouTube-канале, если попал в список лучших. Чтобы перейти из стадии заявки в стадию «Отличный доклад! Надо запостить об этом в Facebook» требуется много времени — порой месяцы. В это время спикеру помогает Программный комитет: структурирует мысли, убирает лишнее, ищет примеры, смотрит презентациею и выступления. Но эту работу мало кто видит. Как у айсберга 90% массы спрятаны под водой, так и 90% работы над докладом спрятаны от глаз.

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

От заявки до сцены. Жизнь доклада на Saint TeamLead Conf 2019 - 1
Читать полностью »

Как проверить идеи, архитектуру и алгоритмы без написания кода? Как сформулировать и проверить их свойства? Что такое model-checkers и model-finders? Требования и спецификации — пережиток прошлого?

Привет. Меня зовут Васил Дядов, сейчас я работаю программистом в Яндексе, до этого работал в Intel, ещё раньше разрабатывал RTL-код (register transfer level) на Verilog/VHDL для ASIC/FPGA. Давно увлекаюсь темой надёжности софта и аппаратуры, математикой, инструментами и методами, применяемыми для разработки ПО и логики с гарантированными, заранее определёнными свойствами.

Это первая моя статья из цикла, призванного привлечь внимание разработчиков и менеджеров к инженерному подходу к разработке ПО. В последнее время он незаслуженно обойдён вниманием, несмотря на революционные изменения в подходе и инструментах поддержки.

Не буду лукавить: основная задача статьи — возбудить интерес. Так что в ней будет минимум пространных рассуждений и максимум конкретики.

Инженерный подход к разработке ПО - 1

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

Даже в очень крупных компаниях часто отношение к разработчикам, как к грибам: держат в темноте и кормят навозом. Пишите код, родные, и не высовывайтесь. Этот подход может быть удобен для многих (в том числе иногда — для самих разработчиков в случае не очень адекватного менеджмента), но с точки зрения бизнеса неоптимален. Моя позиция: разработчики должны иметь возможность узнавать всё то, что происходит в компании и на рынке, но без давления. Захотел — копнул и разобрался, не захотел — не надо.

Редко когда разработчик не хочет понимать, зачем и что он делает. Редко кто не хочет видеть влияния реализованных фич на мир вокруг. Да ладно, давайте будем честными: мы тут все или из-за денег, или из-за возможности делать что-то значимое. Деньги есть везде. А вот интересные проекты встречаются реже.

Я хочу поделиться процессом того, как у нас устроено такое информирование в команде Туту.ру. Возможно, кому-то оно покажется ликбезом, а кому-то будет полезным. Ну или вы подскажете, как сделать лучше. Читать полностью »