В статье я расскажу о моём опыте работы на должности тимлида в компании по разработке сайтов. Чтобы всем было полезнее и проще читать, статья разбита на главы, каждая из которых рассказывает об одной отдельной проблеме и её решению. Хотя по возможности будет сохранена хронология событий.
Надеюсь, что описанный ниже опыт станет для кого-то чужими граблями, а в комментариях я и сам почерпну что-то от более опытных коллег.
Как только вы начали бояться своей технологии, вскоре появятся новые причины для страха.
Петля страха затягивается так:
Сегодня день программиста, 256-й день в году. И мы решили написать пост не для наших коллег-разработчиков, а для тех, кто рядом с ними и с нами. Для тех, кто доводит нас до белого каления, заставляет закипать мозг, выпускать пар и нервно рассказывать о сущностях, интерфейсе и причинах сорванного дедлайна. Для вас, дорогие менеджеры, коммерсы, аналитики, руководители без ИТ-бэкграунда и прочие офисные друзья.
Если вы читаете Хабр, то скорее всего, вам приходится общаться с программистами, просить у них допилить фронтенд или бэкенд сайта, изменить код аналитики, повесить очередной фрагмент кода в шапку сайта, сделать доработки ПО для клиента и многое другое. Так как найти общий язык с разработчиком, чтобы не поссориться? Мы кое-что знаем об этом.
Вечер. Очередное R&D-собеседование подходит к концу, и наши интервьюеры настраиваются на неожиданные вопросы от будущего коллеги. Но никаких сюрпризов: соотношение, выведенное Вильфредо Парето, работает и здесь. В 80% случаев мы слышим четыре вопроса — примерно 20% от общего числа получаемых. Как у вас устроен процесс? Чем я буду заниматься? Как стать сеньором/тимлидом за год? Что по поводу релокации в Европу?
В этом посте мы ответим на первый вопрос и расскажем о процессе разработки в Veeam — от команды к команде этот ответ изменяется меньше всего.
Рассказ о том, что нужно учесть, чтобы выстроить качественную архитектуру вашего проекта. Как сделать его непотопляемым, а клиентов — довольными.
Ниже мы рассмотрим реальные примеры из жизни и попытаемся научиться на чужих ошибках. А попутно составим книгу полезных рекомендаций для solution-архитектора. Во всех историях — архитектурные задачи, которые начинаются с первичных требований клиента и сопровождаются дальнейшим разбором полетов.
В основе статьи — доклад Алексея Богачука (solution-архитектора компании EPAM) с конференции HolyJS 2018 Piter. Под катом — видео и расшифровка доклада.
До Saint TeamLead Conf, конференции про боли тимлида, осталось две недели. В этой конференции мы уже не хотели просто обозначить как можно больше проблем, а хотели раскрыть каждую тему с разных точек зрения. Мы с программным комитетом, основываясь в том числе и на февральской TeamLead Conf, собрали воедино все основные направления деятельности тимлида (не будем забывать, что пока все вкладывают в эту роль разное). Полученное обобщили, структурировали и использовали как кирпичики для построения программы: коммуникации; измерения и оценка; работа со знаниями; построение команды и выстраивание процессов; мотивация команды; и работа над собой, которая и включает то самое: «Я стал тимлидом, и что теперь».
Расписание получилось, как мне кажется, очень взвешенное и сбалансированное, по каждому из 10 направлений есть несколько докладов, причем выступления внутри одной секции идут друг за другом и участнику не понадобится выбирать, какой доклад про коммуникации ему интереснее. Просто приходишь 24 сентября, в понедельник, во второй зал, удобно располагаешься, раскладываешь брошюру и блокнот — и впитываешь чужой опыт. В перерывах задаешь вопросы и общаешься с «коллегами по несчастью». Это будет удобно, и, мы надеемся, позволит каждому найти советы под свои задачи.
Под катом коротко о каждой теме, чтобы показать вам нашу продуманную структуру конференции. Но доклада 32, поэтому в целом это длинно.
TL;DR: Вот ссылка на расписание, можно потыкать только в отдельные доклады — в них всех много живого опыта, практики и вполне конкретных рекомендаций.
Читать полностью »
В начале 2017 года мы, команда разработки ПО для QIWI Терминалов, собирали пожелания подразделений компании — узнавали, какие глобальные задачи коллеги хотели бы решить с нашей помощью, чтобы жизнь стала проще.
Больше всего порадовал запрос клиентского сервиса, работающего со звонками и претензионкой от плательщиков:
“Есть проблема: клиент совершает платеж на терминале, но до процессинга он так и не доходит — или терминал мог зависнуть, или интернет, работающий через gsm-модем, отвалился. И получается, что чек у клиента есть, а платежа в системе нет. Хорошо было бы в таких случаях научиться доставлять платежи в QIWI.
Есть также группа тревожных клиентов, которые сразу после совершения платежа набирают номер колл-центра с целью удостовериться, все ли с ним хорошо. Было бы здорово срезать косты на такие звонки.”
Так у нас появилась комплексная задача: научиться создавать платеж в случае сбоя связи с терминалом и снизить количество входящих звонков от клиентов, придумав инструмент самообслуживания для проверки статуса платежа. Кейс понятен. Стали искать решение, удобное для клиента и без рисков для безопасности.
Читать полностью »
Это краткое отступление в текущей серии статей о том, как избегать введения сервисов для различных сущностей. Интересный разговор за ужином привёл к мыслям, которые я решил записать.
В 1967 году Джин Амдал представил довод против параллельных вычислений. Он утверждал, что рост производительности ограничен, поскольку только часть задачи поддаётся распараллеливанию. Размер остальной «последовательной части» отличается в разных задачах, но она есть всегда. Этот довод стал известен как закон Амдала.
Если построить график «ускорения» выполнения задачи в зависимости от количества выделенных ей параллельных процессоров, вы увидите следующее:
Это асимптотический график для фрагмента, который не поддаётся распараллеливанию («последовательная часть»), поэтому существует верхний предел максимального ускорения
Читать полностью »
Нам пишут:
«Хм, а дайте плиз совет.
Реальный кейс, три разработчика, один разработчик работает 100% времени удаленно, второй разработчик — шеф/соучредитель, третий — немного офигевающий новоприбывший.
Общие совещания — раз в полгода и дальше слов дело не идет. Внедрить GIT для всех разработчиков не получается, все завалены текущей работой.
Есть ли способы как-то улучшить ситуацию?»
У нас юбилей — на хабраблог Яндекс.Денег подписалось 500 человек. В честь этого запускаем экспериментальную рубрику — берём вопрос одного из читателей, связанный с рабочей ситуацией, и бережно передаём его коллегам из Яндекс.Денег, которые знают жизнь. О сегодняшнем вопросе некоторые подумали, что я их разыгрываю и специально придумал такую странную ситуацию. Удивительно, но нет.
Когда проектов становится чуть больше чем один, возникает необходимость как-то переиспользовать не только отдельные модули с кодом, но и сами UI-компоненты. Вариантов решения проблемы много — от традиционного копипаста, до настройки отдельного проекта с тестами, документацией и даже блекджеком.
Проблема в том, что второй вариант требует значительных усилий по подготовке и каждый такой проект уникальный — со своим инструментарием в котором каждому новому разработчику нужно разбираться заново. В конце июля, команда Angular предложила свое, комплексное, решение этой проблемы добавив в angular/cli новую команду для создания библиотек — library.
Давайте посмотрим, что из этого получилось.
Для тестов, взята самая свежая из стабильных версий angular/cli — 6.1.5 (04.09.2018)
