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

Разработка должна ориентироваться на продакшен, всё остальное — чушь - 1

За мою карьеру у меня выработались определённые мнения. Некоторые из них оставили особенно глубокий след, подкреплённый годами опыта. Я попытался сформулировать, что же у них есть общего. Общее заключается в мысли о том, что единственное, что важно — это код в продакшене. Обкатка не важна, код на твоём ноутбуке не важен, QA не важен, важен только продакшен. Всё остальное — это технический долг.

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

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

Закроем тему прокрастинации - 1

Лет 20 назад люди тоже ленились. Но термин «прокрастинация» хоть уже существовал (с 1970-х), но не был знаком абсолютно всем, как сейчас. Мне кажется, у нас эпидемия. И, кажется, я знаю почему и что с ней можно сделать. Во всяком случае, у меня работает. И откладывать чтение на потом не придётся – всего 3 правила, уложусь в 5-7 минут Вашего времени

Правило 1: фокус внимания на цели

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

Как не испортить своего джуна - 1

Меня зовут Дима Вдовин, я разработчик команды корпоративных рисков. Сегодня я хотел бы поговорить о джунах и их интеграции в команду разработки. С одной стороны, тема банальная и известна всем, а с другой, о ней часто забывают или игнорируют. Почему-то многие команды и руководители считают, что джун вольется в коллектив и работу над проектом как-то «самостоятельно», без активной поддержки, а если не вольется — значит он не справляется и не подходит. Это не так.

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

Наша группа по оптимизации производительности нашла маленькое изменение, которое оказало большое влияние на скорость сборки по всем конвейерам. Мы обнаружили, что установка параметра refspec во время git fetch ускоряет шаг клонирования в 100 раз.

Группа Engineering Productivity отвечает за поддержку инженеров, которые создают и развёртывают программное обеспечение в Pinterest. Наша команда поддерживает ряд инфраструктурных сервисов и часто работает над крупными проектами — перенос всего программного обеспечения на Bazel, создание платформы непрерывной доставки под названием Hermez. Они же поддерживают монорепозитории, куда ежедневно присылают по несколько сотен коммитов, и это ещё не все их задачи.
Читать полностью »

Направление Site Reliability Engineering становится всё более популярным. Хайп не на пустом месте: проблемы и задачи, которые решает SRE, действительно насущны для многих компаний.

Популярность SRE растёт, но знаний о нём всё ещё недостаточно. Я не буду повторять формальные определения, а вместо этого расскажу несколько историй из жизни системного инженера Лёхи. Путь выдуманного Лёхи во многом похож на путь, который прошли реальные крупные компании, где впервые и возникли SRE-инженеры (даже если назывались иначе).

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

— Люди не из индустрии вечно не понимают программистов: что они там такое сложное делают, если видно только две кнопки? Что за непонятные слова говорят? Почему так много получают?

Вместе с парнями из подкаста «Мы обречены» решили с этим разобраться и запустили совместную рубрику, где будем объяснять, почему в разработке всё так сложно. А для тех, кто любит читать, а не слушать, парни написали эту статью.

Разрабы работают медленно и дорого — и люди считают нас лентяями. Просто в разработке всё сложно - 1

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

Не делать работу дважды - 1

30 сентября на конференции DevOps Live прозвучал доклад «Активация обмена знаниями» об обмене опытом и том, как бороться с двойной работой. Под катом — доклад в текстовом виде, обогащённый некоторыми деталями, и видео с докладом.

Почему мы вообще говорим об обмене знаниями?

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

Последние несколько лет мы при каждом удобном случае снова и снова обсуждаем, что же такое DevOps. Это уже порядком надоело, но раз всё еще происходит, значит есть проблема — проблема взаимодействия бизнеса и инженеров.

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

Почему бизнес хочет DevOps и что нужно знать инженеру, чтобы говорить с ним на одном языке - 1

Я не хочу рассуждать о том, что такое DevOps и какое его понимание более правильное. Мне интересно проследить за эволюцией процессов в IT и разобраться, что бизнес хочет получить от внедрения DevOps, что это значит для инженеров и как нам быть на одной волне.
Читать полностью »

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

От тимлида зависит многое — эффективность команды, достижение поставленных целей, профессиональный рост сотрудников. И чтобы разобраться в нюансах работы тимлида, мы поговорили с Иваном Михеевым, Deputy CTO в компании AGIMA. У Ивана многолетний опыт управления большими командами, включая отдел разработки с общей выработкой от 10 000 до 15 000 часов в месяц: PHP, Python, Mobile, Front-End, DevOps, QA.
Читать полностью »

Данные тезисы основаны на 14 летнем опыте и полезны инвесторам, руководителям и сотрудникам RnD отделов, и специалистам по подбору кадров (для задачи грамотных вопросов на собеседованиях).

Тема как нужно заниматься техническими разработками актуальна лет 70, книг написана масса и заголовок у этой статьи кликбейтный, но это вынужденная мера, ибо продолжаю из раза в раз сталкиваться с одними и теми же примитивными ошибками. В большей мере это актуально для технарей и в меньшей — для айтишников:

  1. Финансовое расточительство
  2. Нереальный продукт
  3. Выдавать желаемое за действительное при проведении валидации и верификации продукта
  4. Несоблюдение сроков в календарном плане
  5. Смена приоритетов в процессе выполнения плана
  6. Неоптимальное проведение совещаний
  7. Работа с непроверенным субподрядчиками и поставщиками
  8. Отсутствие однозначной и неизменной нумеровки документации. Изменение нумеровки документации в процессе работы над проектом
  9. Добровольно-принудительное изменение обязанностей у сотрудников в процессе
  10. Соглашение о неразглашение заключается после увольнения сотрудников

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


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