Ответы пользователя по тегу Управление проектами
  • Наименование вакансии?

    mazhekin
    @mazhekin
    Frontend, Backend Web Developer
    Это девопс инженер, а не техлид

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

    Например, когда человек называет свою специализацию сразу понятно чем человек занимается на проекте, то ли это девопс-инженер, или ux-дизанер, или скрам-мастер, тестировщик, бекенд-разработчик, фронтенд-разработчик. Вопросов нет, понятно чем люди занимаются и за что отвечают. Техлид или тимлид, обычно туманно и непонятно объясняет свою позицию на проекте и владеет всем по чуть-чуть, но ничего глубоко и профессионально.
    Ответ написан
    Комментировать
  • Когда заказчик просит просто дописать?

    mazhekin
    @mazhekin
    Frontend, Backend Web Developer
    Законченный, якобы, проект с кривым кодом(архитектурой) - это как дом с кривым фундаментом, зачастую у него не то что низкая, у него отрицательная стоимость. То есть с нуля действительно дешевле переписать будет. Но как избежать повтора ситуации (когда вроде бы все готово, но по мелочам ничего не работает)? Для этого нужно заказчику или руководителю проекта добиватся законченных изолированных микро-решений на каждом участке (на каждой форме - диалоге - старнице). Нужно не боятся и менять первоначальные решения (просить дополнять или изменять функционалность) и смотреть как програмист будет подстраиватся под изменившиеся бизнес-требования (это реальные ситуации которые будут возникать в промышленном использовании продукта от пользователей). Если программист застревает - это и есть реальная скорость разработки проекта и признаки что проект не будет доведен до конца и выведен в эксплуатацию. А то что заказчику. там "архитекторы" накидывают код, и говорят что там все сделано и надо только дописать - это разработка нулевая или даже с минусовой стоимостью.

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

    Ну начинается проект все ок. Программист пишет - пишет вроде бы начинают появляться рабочие экраны или работающий функционал, но он не следит за чистотой кода, игнорит или не знает рекомендованные стайлгайды, стиль кода постоянно меняется, все накручивается на базовых примитивах типа for-if, нарушаются декомпозиционные сущности, рефакторинг собственного кода (для дальнейшего облегчения понимания) отсутствует (главное чтоб работал). Постоянно его костылит. И код превращается в кучу крепко завязанного, запутанного говна. Попытки внести фиксы или дополнительный функционал в такой код приводят к ещё большим проблемам. Причем снаружи - это действительно выглядит как будто что то не работает по мелочам. Но поддержка и развитие такого проекта останавливается и автору коду уже невмоготу с ним работать, потому что петля этого монолита уже крепко затянута. И человек либо тянет время и просит нанять ещё разработчиков, либо просто уходит на "лучший офер". Заказчик думает что там осталось совсем чуть чуть. И любая попытка погрузить нового программиста в этот проект проваливается.

    Объясняйте заказчику, что код очень сильно запутан. Приводите упрощенные примеры запутанности и приводите примеры их решения. Воспринимайте этот запутанный проект - как челендж для себя. Думайте о том, что если вы его распутаете, поблочно перепишете и разложите все по полочкам, ваша стоимость увеличится в разы как специалиста. Оцените свои силы, научитесь жёсткому параллельному рефакторингу вместе с текущими задачами, декомпозируйте код на части, изолируйте части кода. Заказчику не произносите слово "рефакторинг". А писать с нуля - это не вариант. Вы просто протянете время и не факт, что не придёте к тому же, что сделал предыдущий разработчик. И потом свалите. Лучше научитесь плавно метаморфизировать проект при этом выполняя текущие задачи.

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

    И самый интересный финт, получается такой, что в глазах заказчика автор(источник проблем и говнокода) будет выглядеть как некий профессионал с гениальным кодом и архитектурой, код которого никто понять и поддерживать не может, потому что якобы все приходящие на проект не достаточно квалифицированы.

    Да... работа такая у программиста запутанное(сложное) делать понятным(простым), а не наоборот.
    Ответ написан
    Комментировать
  • Какие книги посоветуете для будущего Team Lead'a?

    mazhekin
    @mazhekin
    Frontend, Backend Web Developer
    В сторону тимлида не надо развиваться - это промежуточное состояние, неопределившегося пока специалиста - и не программист (зачастую программировать уже не охота и начинают утрачиваться программистские скилы), и не управленец (не успевает освоить нужные знания по управлению), просто пока думает куда развиваться дальше, либо продолжать программировать, проектировать ПО и развиваться сильным техническим спецом (айти архитектура), либо углубляться и переходить в профессиональное управление разработкой и становиться скрам-мастером. Профессии будущего.
    Ответ написан
    Комментировать
  • Что вы делаете с программистами, которые завалили спринт?

    mazhekin
    @mazhekin
    Frontend, Backend Web Developer
    Не спешите, пройдите еще пару-тройку спринтов, выясните реальную скорость команды (https://www.scruminc.com/velocity/) быть может завалили спринт не потому что плохо работали, а ошиблись в оценках. Декомпозируйте с командой большие таски, на более мелкие. Их легче оценить точнее. А таск трекер вам их просуммирует автоматически и вы будете видеть картину в целом. Проводите дейли статусы и выясняйте какие препятствия есть у разработчиков и какой прогресс за один день происходит (что сделано вчера и планируется сегодня). Более плотно работайте с командой. Если команда проигрывает постоянно, и ничего не улучшается, в первую очередь меняют тренера, если он не смог настроить или пересобрать команду так, чтобы она выигрывала.
    Ответ написан
    Комментировать
  • Как вы мониторите количество часов у исполнителей?

    mazhekin
    @mazhekin
    Frontend, Backend Web Developer
    1) тайм трекер https://hubstaff.com устанавливаю на компьютер, запускаю как начинаю работу. Останавливаю как заканчиваю. Программа делает скриншоты. Заказчик всегда может увидеть что и как я делал, каждые 5 минут. Доверие выше и мне спокойнее.
    2) Параллельно логгирую часы в Jira. Там заказчику виден прогресс что сделано и что осталось сделать, и сколько времени было потрачено в сумме и на каждую задачу в отдельности. Также есть суммарные отчеты, для отслеживания процесса в целом.
    3) Git там код. Но как правило это заказчикам не совсем понятно и не интересно, они смотрят в основном готовый продукт, отчет по времени, и по задачам.

    Ps. Чтобы выявлять отклонения в разработке на ранних этапах и понять удорожание продукта проконсультируйтесь или наймите хорошего скрам-мастера.
    https://biz.mann-ivanov-ferber.ru/2018/06/05/kto-t...
    Ответ написан
    Комментировать