Ответы пользователя по тегу Управление проектами
  • Как вести базу знаний всех обновлений, исправлений и изменений, вносимых в проект?

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    1. commit message
    2. task tracker (JIRA или аналоги)

    Если их интегрировать друг с другом, будет еще и довольно просто перемещаться по коммитам
    Ответ написан
    Комментировать
  • Как максимально продуктивно изучить кухню SDLC?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    Пообщайтесь с девопсами и архитектором.
    SDLC делается не на с++ а автоматизацией процесса.
    Пулл реквесты, дженкинсы, битбакеты, гитхабы, конвеншены по бренч нейминг, по гит флоу, по процедуре релиза.
    Ответ написан
    Комментировать
  • Можно ли в telegram помеченные ключевым словом сообщения в группе автоматически переносить в другой чат группы?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    1. хештеги
    2. можно своего бота написать, который будет автоматом перекидывать нужные, или закреплять их.
    Ответ написан
    Комментировать
  • Стоит ли разработчикам платить за баги?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    Спорил со своим коллегой на днях - стоит ли платить разработчику за то, что он исправляет собственный баг.


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

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

    Ну и не платить за работу - останетесь без разработчиков.
    Ответ написан
    Комментировать
  • Как правильно находить готовые коды, плагины на разных языках?

    saboteur_kiev
    @saboteur_kiev Куратор тега Программирование
    software engineer
    Вопрос, наскольким может быть эффективным, для снижения стоимости разработки пробной версии, такой подход, не писать с нуля, а соединять куски программ или целеком в зависимости от ТЗ?


    Ну глупый вопрос же.
    Если ты считаешь себя предпринимателем со стажем, то давай упростим твой вопрос до такого:
    Хочу выпускать автомобиль, но хочу все упростить. Есть же куча готовых автомобилей, я же могу взять сфотографировать свой мерседес, потом разробрать Москвич и приделать детали? Там же много похожих кусков?

    Но ты же понимаешь что это бред. При этом считаешь что программирование это другое, и там соединить куски легко?
    Так вот.

    Нет, не легко.
    Нет, не всегда возможно это сделать нормально, проще написать с нуля.
    "С нуля" в данном контексте уже подразумевается далеко не с нуля - есть огромное количество готовых фреймворков и библиотек, которые хорошо документированы и как раз и используются как готовые куски кода.
    Вопрос следует задавать после детального ТЗ, тем программистам которые будут это делать.
    А у рандомных людей в инете задавать вопросы вообще не приводя никакие детали - какой бы процент эффективности тебе не назвали - он не будет соответствовать конкретно твоей задаче. Спроси у своих программистов.
    Ответ написан
    1 комментарий
  • Нужен совет/помощь в вопросе пути к управленческим/бизнес направлениям/Product Manager. Есть ли примерная "дорожная карта"?

    saboteur_kiev
    @saboteur_kiev Куратор тега Карьера в IT
    software engineer
    довольно сложная задача. Можно поискать проекты, где нужен второй менеджер, помощник/заместитель - такие проекты есть и много.

    Что нужно знать - чем hardware сервер отличается от vps, а тот от vps в облаке, а тот от виртуальной машины а тот от контейнера. Почему? Потому что менеджер зачастую аппрувит ресурсы в компанию и должен примерно понимать, почему его проект требует столько всего для тестовых енвайрнметов и продакшена

    Почитать про отказоустойчивость, понимать сколько в нее нужно закладывать в зависимости от вашего проекта. Ответственность за риски принимаете вы, вам их могут только примерно сообщить снизу.

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

    2. Как бы вы посоветовали мне двигаться в этом направлении?
    Это странный вопрос. Если у вас есть возможности, знакомые в этой теме - можно у них узнавать. А так - кто знает. Если вы в жизни не писали код, но являетесь адекватным человеком - то я видел и таких руководителей, и в принципе нормально. Менеджер и не должен заниматься микроменеджементом, для этого есть тимлиды. И ИТ прошлое может и помочь, и помешать, тут важно что за человек и умеет ли он ставить приоритеты правильно.

    2. Если нужно выучить технические основы - то что-бы посоветовали, какие языки, навыки, позиции? Я готов посвятить время, изучить вникнуть стать джуном-мидлом. Вопрос в каком направлении двигаться?
    Двигайтесь в сторону тестирования и автоматизации. Это поможет понимать процесс производства продукта лучше, так как хорошее тестирование в продукте, зачастую занимает больше времени, чем разработка. И менеджер больше работает с тестировщиками и бизнес-аналитиками - с ними обсуждаются бизнес требования, с ними обсуждаются и сайн офф на продукт.

    3. Какой плацдарм будет лучше для достижения цели? Тестирование, веб, языки какие-то, маркетинг, либо что-то другое?
    Управление, естественно.

    5. Может есть dual-study истории в этой сфере? Либо возможности Стажировк у ПМ, помощником ПМ?
    Есть такие случаи и много. Но в проектах от среднего и выше, так как в маленьких проектах много руководства не требуется.
    Ответ написан
    1 комментарий
  • Как правильно тестировать бизнес-идею?

    saboteur_kiev
    @saboteur_kiev Куратор тега Книги
    software engineer
    Бизнес план включает в себя реалистичные расчеты по затратам на реализацию идею и реалистичные расчеты на отбивание средств этой бизнес идеей.
    Если тебе нужно просто написать какой-то бред для преподавателя - пиши любой бред.
    Если нужно более-менее рабочее, надо реально выяснять все нюансы и считать деньги.

    Без денег - это не бизнес план, а просто план, точнее еле-еле набросок плана.
    А с деньгами - сразу становится понятно насколько эта идея реалистична. Зачастую под бизнес-план деньги может дать инвестор под разные условия (проценты от заработка, процент от продукта, или вообще владение контрольным пакетом). Но без реалистичных и убедительных расчетов, где ты сможешь обосновать, когда и сколько ты сможешь заработать - никто не пошевелится.
    Ответ написан
    Комментировать
  • Как более точно оценить время разработки ПО?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    Оценка времени приходит с опытом.
    Никакая инструкция или утилита не поможет за вас рассчитывать время вашей творческой работы.

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

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

    Подытожу этот словесный поток:
    Помогает опыт. Индивидуальный и командный.
    Ответ написан
    Комментировать
  • Разработчик недисциплинированно трекает время. Что делать?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    Если оценка превышает запланированную более на 30 процентов

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

    Как менеджер, вы должны учитывать этот момент, и составлять характеристику на людей, тасовать их в разные команды, назначать им разные задачи (или делегировать микро-таймменеджмент на тимлидов).

    Если же хотите математику - готовьтесь к тому, что у вас будет большая текучка, пока вы не сможете укомплектоваться молодцами, одинаковыми с лица, то есть примерно одинаковыми. Но это займет уйму времени (то есть денег). Собственно одна из работ менеджера состоит в том, чтобы правильно распределиться ресурсами, а это в том числе и людьми.
    Ответ написан
    1 комментарий
  • Может ли тз предоставляется как услуга?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    Если ТЗ достаточен для работы и обе стороны считают, что они понимают его правильно - то отлично.

    Если же ТЗ недостаточен по мнению одной из сторон, то его доработка может быть как за деньги, так и бесплатно.

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

    saboteur_kiev
    @saboteur_kiev
    software engineer
    Если вы знакомы с проектом и разобрали что за баг, то оценить время на его устранение не проблема.
    Если вы не знаете что это за баг, то это еще не баг а production issue, и происходит его investigation до того момента, пока вы не придумаете временный workaround, чтобы пользователи могли работать, потом вы найдете root issue, заведете баг и уже тогда оцените время на его исправление.

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

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

    Agile в этом плане удобен не только тем, что можно накидать себе задач на 2-3 недели и их решать, а тем, что каждые 2-3 недели можно посмотреть назад, и понять насколько хорошо ты оценил свои естимейты, и нужно ли в следующем спринте увеличивать или наоборот уменьшать время. И так каждый спринт - смотришь и улучшаешь навыки планирования и эффективность работы.
    Ответ написан
    10 комментариев
  • Что делать,если не успеваем закончить юзер сториз во время?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    Непредвиденные обстоятельства должны были быть прописаны в контракте с заказчиком, и ответственность за срыв сроков там также должна быть описана.
    Если указанные непредвиденные обстоятельства указаны в перечне форс-мажора, может быть даже и ответственности никто не понесет. Если же нет - согласно контракту (штрафы, печеньки).

    Вопрос вообще больше к юристам и к менеджменту, а не аналитикам.
    Ответ написан
    Комментировать
  • Что проджекту делать с недооценкой времени?

    saboteur_kiev
    @saboteur_kiev Куратор тега Веб-разработка
    software engineer
    Agile технологии хорошо работают в опытной команде. Поэтому со временем и тимлиды и вы должны лучше справляться с оценкой.
    * Со стороны лидов - качественнее прогнозы, качественнее оценка работы подчиненных
    * С вашей стороны - корректировка самого agile процесса - размер спринтов, количество и время на митинги, размер буфера.

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

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

    Вообще, всегда в сложных тасках, они должны дробиться на более мелкие, вот уровень этого дробления и подбирается в каждом проекте на опыте.
    Ответ написан
    Комментировать
  • Как научится давать сроки по проекту?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    Сроки зависят сугубо от человека, от его навыков, его опыта, его самоорганизации.
    Каждый должен сам научиться определять с какой скоростью он работает.

    У многих новичков не хватает ни опыта ни самоорганизации, поэтому записывайте свою работу и затраченное время, анализируйте.
    Ответ написан
    Комментировать
  • Как правильно вести и заканчивать проекты?

    saboteur_kiev
    @saboteur_kiev Куратор тега Веб-разработка
    software engineer
    Потому что программист, менеджер проекта, бизнесмен-стартапер - это все разные профессии, для которых нужен свой комплект навыков, знаний и опыта.

    Цикл разработки не для того, чтобы закончить проект. Цикл разработки для того, чтобы быстрее выпускать новые версии продукта. И да, совершенно естественно, что такая информация отсутсвует в учебниках по ИНФОРМАТИКЕ или ПРОГРАММИРОВАНИЮ, это ближе к менеджерам.

    Но менеджеры и бизнесмены тоже не всегда могут взлететь со своим проектом или своим бизнесом.
    Ответ написан
    Комментировать
  • Какие есть современные решение для хранения исходников проектов в компании?

    saboteur_kiev
    @saboteur_kiev Куратор тега Git
    software engineer
    у вас же уже есть тег git в вопросе.
    В git и хранятся.

    Количество версий вообще не говорит о размере проекта. Кто-то каждый коммит называет новой версией. У кого-то между двумя версиями сотни и тысячи бренчей и слияний.

    Гит часто используется не сырым, а с какой-нить оболочкой (gitlab, gerrit, bitbucket/stash) или даже сразу с хостингом на том же github.
    Ответ написан
    5 комментариев
  • Как правильно релизиться в больших компаниях?

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    Правильные версии - более универсальный вариант. Вдобавок те же фича-тимы могут работать и с версиями.
    Чтобы упростить работу с версиями, используйте https://semver.org/lang/ru/

    Скажем так. На организацию эффективных фича-тим уйдет больше усилий, чем на версионирование.
    Ответ написан
    Комментировать
  • Что не так с качеством разработки?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    Не зная внутренней кухни этих компаний, вы считаете что у них полно времени.
    Но ведь вы не знаете, сколько на самом деле работы и в каких направлениях развиваются эти продукты?

    Взять Касперский - свыше 4000 человек в 32 странах. То, что компания уже не развалилась за столько времени - показатель уровня менеджмента гораздо выше среднего. И понятно, что компания такого размера имеет свое видение на бизнес и действительно важные фичи, благодаря которым можно оставаться на рынке, и держаться в топе этого рынка.
    А вы тут про какой-то красивый код.. =)
    Ответ написан
    Комментировать
  • Как спланировать проект?

    saboteur_kiev
    @saboteur_kiev Куратор тега Веб-разработка
    software engineer
    Планирование проекта это немного другое. Это оценка времени на выполнение проекта, оценка стоимости проекта, оценка дополнительных расходов (еще один напарник), и договоренность с клиентом о сроках, конфирме промежуточных итогов и так далее.
    А инструменты нужно выбирать в зависимости от ваших навыков.
    Ответ написан
  • Есть ли ISO описывающий позиции в отделе обеспечения качества?

    saboteur_kiev
    @saboteur_kiev Куратор тега Карьера в IT
    software engineer
    Стандарта в коммерческих компаниях как такового нет, точнее его необязательно придерживаются.
    Есть стандарт для бухгалтерской отчетности, но для этого вы уточните страну проживания.

    Если вы захотите по официальному стандарту, то там "process manager/QA director" однозначно не существует. Можно будет подобрать русскоязычный аналог.
    Ответ написан
    Комментировать