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

Последние несколько лет мы при каждом удобном случае снова и снова обсуждаем, что же такое 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. Соглашение о неразглашение заключается после увольнения сотрудников

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

Нужна справка на каждого ребенка. Да, и согласие на обработку персональных данных. От каждого из родителей. Пусть и анкету каждый заполнит. Статистический отчет о том, сколько мальчиков и девочек. Да, и по возрастам. И по районам прописки. Ну и по школам. Разделите там, пожалуйста, обычные школы, лицеи и гимназии. Нет, педсовет пропускать нельзя. Это всего 4 часа. Раз в неделю. Да, всем педагогам надо прийти. Конечно, вам нужно работать еще и в детских садах. Каждому из вас. Трижды в неделю. И костюмы ваши нам не нравятся, нужно меньше красок – чего как попугаи-то?

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

Примерно так описал один очень хороший руководитель одного очень хорошего танцевального коллектива жизнь «под крылом» государственного учреждения, когда объяснял, почему ушёл «из-под крыла».

Случай запал в душу, т.к. я как раз проводил эксперимент (в очередной раз) по избавлению других творческих людей – программистов – от непрофильной, но «такой важной, нужной и обязательной работы» — успеванию в срок.Читать полностью »

Не нужно делать из фреймворков культ — они не настолько сложны, чтобы делить людей на React и Angular разработчиков - 1

Недавно меня позвали гостем в «Тяжелое утро с Holy.js», чтобы хорошенько пропесочить за мою статью про глупцов-фронтендеров. Мы обстоятельно поговорили, и один из аргументов был такой — если наши js фреймворки жрут неоправданно много на простых задачах — просто не используй их. Если тебе просто надо порендерить четыре формы, то тебе не нужен ни реакт, ни тайпскрипт, ни вебпак — ничего. Создаешь три файлика .html, .css и .js — вот тебе и приложение.

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

Есть на свете странные люди. Программисты, за которыми не надо проверять ни работоспособность решения, ни качество кода. Руководители проектов, которых не надо контролировать. Тимлиды, которые никогда не говорят «ну, не шмогла я…».

У них тоже случаются провалы, но рука не поднимается, голос не повышается их критиковать или песочить. Ты как будто понимаешь – этот человек точно сделал всё, что было в его силах.

Они редко просят помощи. Бывает, что ресурсы запрашивают, необходимые для выполнения работы. Но отказ в помощи их не расстраивает, а, кажется, наоборот – радует и бодрит. Как вызов – решить задачу в ограниченных ресурсах.

Вы таких людей наверняка видели. Возможно, в зеркале. Я долго думал, в чём причина подобного поведения. Особенно смущает тот факт, что они не всегда были такими – что-то, когда-то, с ними произошло, превратив их из «сделаю, если смогу» в «сделаю всё, что смогу».

Прошерстив всех знакомых за 15 лет, которые подходят под приведенное описание, в т.ч. самого себя, я пришел к выводу: причина в том, что эти люди когда-то оставались в одиночестве. Только его формы были разными.Читать полностью »

В стародавние времена я, на постоянной основе, занимался техническими собеседованиями – отбирал кандидатов на должность программиста в компанию. У меня была простая, понятная, шикарная методика (не мной придуманная). Чувак сначала проходил длинное собеседование по куче разнообразных вопросов, потом решал несколько задач. На бумаге, как мы делали в ВУЗе.

Оглядываясь назад, понимаю – отбор действительно работал шикарно. Все, кого я тогда отобрал, стали уважаемыми в нашей деревне специалистами. Больше половины из них давно открыли собственный it-бизнес, в самых разных сферах – от 1С до разработки CRM-систем.

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

Работа инженера — сплошное разочарование. Возможно, потому что у нас нет власти, а менеджеры сбрасывают на инженеров все проблемы и ожидают, что они будут решены к вчерашнему дню.

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

Вот общий сценарий, который разыгрывается между инженером и его боссом, инженером-менеджером. Менеджер спрашивает, сколько времени займёт выполнение новой задачи. Бывает, что инженер не делал эту задачу раньше, поэтому честно отвечает, что понятия не имеет. Менеджер не принимает такой ответ — и снова спрашивает. Тогда инженер даёт оценку практически наугад, а босс отвечает: «Это слишком долго». Даже если инженер знает, сколько времени займёт выполнение задачи и даёт реалистичную оценку, менеджер часто отвечает: «Это слишком долго. У тебя есть время до пятницы». Когда инженер спрашивает, как давно стало известно об этой задаче, босс отвечает, что месяц назад. Когда инженер спрашивает, почему он не сказал ему об этом месяц назад, тот просто смотрит на инженера, как будто не понимает вопроса.
Читать полностью »

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

Дорожная карта развития продукта: Курс Создание программного продукта и управление его развитием - 1
Читать полностью »

Как перенести на TypeScript большую кодовую базу React UI-компонентов - 1

Привет! Меня зовут Иван Греков, я работаю UI-разработчиком в frontend-команде Badoo. Главные задачи нашей команды — создание новых и поддержка существующих пользовательских интерфейсов для сайтов и приложений Badoo и Bumble. 

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


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