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

Привет. Меня зовут Евгений Удодов, я сооснователь и технический директор компании Roistat. Хочу поделиться нашим опытом разработки большого и сложного продукта — системы аналитики.

TL;DR: Мы выложили на github наш Code Conventions и рассказали в статье о том, как его применять на практике.

При разработке больших продуктов существует распространенная проблема — с течением времени накапливается много legacy-кода, задачи делаются все медленнее и медленнее. Также при росте команды разработчики начинают писать код по-разному и отсутствие единых правил может приводить к конфликтам и спорам.

За 4 года существования нашего проекта мы сделали больше 20 000 Pull Request’ов (далее PR) и под катом я расскажу, как же мы решили эти проблемы.

Code Conventions: как мы сохраняем быстрый темп разработки PHP-проекта - 1
Читать полностью »

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

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

Пролог

— Ты, главное, не ссы! Держись меня, делай как я, и все будет чики-пуки.

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

— Коль, давай посерьезнее. — Жанна строго посмотрела на круглую самодовольную рожу. Потом перевела взгляд на новенького. — Сергей, не слушай этого старого коня. Борозды он, конечно, не испортит, но и целины не поднимет.

Сергею пришлось улыбнуться — все-таки начальник пошутил, и вроде не совсем безнадежно.

— Мы на тебя возлагаем большие надежды, Сережа. Николай у нас под завязку загружен текучкой — ее очень много. Мы понимаем, что действуем неэффективно, где-то что-то упускаем, используем устаревшие технологии и подходы… Но у нас реально нет времени остановиться, подумать, посмотреть, поучиться. Как писал Кови — наточить пилу.

Сергей понимающе покивал головой. Он не знал, кто такой Кови, но метафору понял.

— Ты — молодой, целеустремленный, не обремененный обязательствами и связями, амбициозный, и очень умный программист. У тебя за плечами очная Бауманка. Мы ждем от тебя новой струи свежего вохдуха, скачка в развитии наших систем, прорыва облачных технологий. Так, и только так!

— Спасибо, Жанна Ивановна. Я буду стараться.

— Никакого отчества, просто Жанна! Велкам в нашу команду, Сережа!
Читать полностью »

Продолжение перевода статьи «Big ball of Mud».

ОДНОРАЗОВЫЙ КОД

он же
QUICK HACK (быстрый хак)
KLEENEX CODE (код на салфетке)
DISPOSABLE CODE (утилизируемый код)
SCRIPTING (скрипт)
KILLER DEMO (демо-убийца)
PERMANENT PROTOTYPE (постоянный прототип)
BOOMTOWN (быстро выросший город)

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

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

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

Нужно ли менеджеру уметь программировать - 1

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

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

Апгрейд хранимок Tarantool: «все своё ношу с собой!» - 1

В мире баз данных существует сложная проблема рефакторинга и апгрейда хранимых процедур.

Проблема состоит в противоречии:

  • С точки зрения эффективности работы с данными желательно максимум бизнес-логики реализовывать в хранимых процедурах.
  • С точки зрения эффективности разработки ПО желательно, чтобы части одной программы находились в одном месте. Хранение кода работы с хранилищем прямо в хранилище создаёт много трудностей.

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

Говорят, что не нужно изобретать велосипед. На первый взгляд это кажется очевидным. Если вы потратили время на разработку, то зачем делать это снова, можно ведь повторно использовать старое решение? Казалось бы, со всех сторон хороший вариант. Но не всё так просто. Как старый «седой» программист, я видел, как организации снова и снова становятся жертвами этого заблуждения, вкладываясь в предварительный дизайн и разработку, но никогда не достигая обещанного массивного ROI благодаря повторному использованию. На самом деле я считаю, что наша чрезмерно оптимистичная оценка пользы и простоты повторного использования — одна из самых распространённых и опасных ловушек в разработке ПО.

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

Kubernetes meetup — презентации и вебкаст - 1
Привет!

21 марта в московском офисе IBM прошел митап сообщества Kubernetes. В рамках данного мероприятия участники обсудили последние новости о развитии Kubernetes, обменялись практическим опытом и пообщались с коллегами в неформальной обстановке.

Под катом — подробности, а также ссылки на презентации и видеозапись выступлений.
Читать полностью »

Обзор TeamLead Conf: 2 дня по 2 трека, 25 докладов, 474 участника, излитая боль неизмерима - 1

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

  1. Нужен ли вообще тимлид?
  2. Что есть тимлид, какие у него задачи?
  3. Что сначала: команда или тимлид?
  4. Необходимы ли тимлиду технический навыки?
  5. Вырастить или нанять?
  6. Как понять, можно ли и нужно ли выращивать из инженера тимлида?
  7. Сколько времени нужно, чтобы вырастить тимлида?
  8. Менеджерские роли тимлида, какая роль предпочтительней?
  9. Насколько важны эмоциональный интеллект и социальные навыки?
  10. Что делать если руководитель сам является техническим специалистом и падок на микроменеджмент?
  11. Тимлид ушел на неопределенное время (отпуск, больничный, форс-мажор), что делать?
  12. Что делать, если тимлид уходит насовсем?
  13. Какое должно быть соотношение менеджмента и разработки в работе тимлида?
  14. Есть ли путь назад (и вперед)?
  15. Какие перспективы карьеры тимлида?
  16. Что может помешать стать тимлидом?
  17. В чем разница между тимлидом и техлидом?
  18. Как выявить неэффективного тимлида на ранней стадии?
  19. Как начинающему тимлиду справиться с потоком информации?
  20. Нужен формальный или неформальный лидер?
  21. Junior и Senior тимлид, в чем различия и как держать их в одной команде?

Такой поток запросов выдали участники TeamLead Conf на круглый стол. Если вы уже сталкивались с какими-то из них, то, вероятно, и остальные могут вас настигнуть, есть, о чем подумать.

Под катом — обзор лучших докладов TeamLead Conf с видеозаписями и презентациями.
Читать полностью »

Этой весной выездная конференция ИТ-экспортеров ISDEF Spring пройдет на территории ростовского Южного IT-Парка. Мы попросили наиболее активных спикеров конференции рассказать о том, чем занимается Южный IT-Парк, и что полезного он делает для развития отрасли.

Первым откликнулся активист ISDEF из Таганрога Игорь Шелудько, руководитель FSPro Labs, по совместительству трекер Южного IT-Парка. Игорь не боится, в отличие от многих, делиться в своих кейсах не только успехами, но и анализировать неудачи. В этом году он расскажет об опыте продаж десктопных B2C-продуктов по подписке.
Читать полностью »


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