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

    saboteur_kiev
    @saboteur_kiev Куратор тега Разработка игр
    software engineer
    Рядовые программисты хотели бы поучаствовать в схеме, где им платят хорошие деньги и ставят адекватные задачи.
    Продюсер или спонсор хотел бы поучаствовать в схеме, когда он оплачивает разработку, а она "взлетает", принося прибыль.
    Руководитель проекта хотел бы поучаствовать в схеме, в которой есть нормальный продюсер, нормальные программисты, а сам он имеет адекватные идеи, хороший опыт и способен организовать создание такого проекта.

    ВСЕ ОСТАЛЬНОЕ - это мелочи.
    Ответ написан
    Комментировать
  • Тенденция к перехвату проектов/клиентов сотрудниками с последующим увольнением. Что делать?

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

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

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

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    Методика разработки.

    Waterfall: все тщательно планируем, назначаем сроки, разрабатываем, сдаем.

    Agile: Примерно планируем, анализируем, назначаем конечный срок, планируем на текущую итерацию, разрабатываем, планируем на текущую итерацию, разрабатываем... , сдаем

    Проблемы Waterfall:
    Если кто-то слажал, все ждут. Если нужно что-то добавить, очень сложно, потому что фаза планирования была очень долгой и тщательной и что-либо менять значит надо все менять.
    Если в плане указано, что сперва делаем это, а потом то, может случиться что некоторые люди, которые будут делать "то", будут какое-то время пинать "огурцы" пока ждут что первые люди сделают "это".
    Плюсы Waterfall:
    Все спланировано, все точно знают что когда будут делать.

    Проблемы Agile:
    Люди должны быть достаточно зрелые, чтобы нормально загружать себя работой - Agile в бюрократической среде просто провалится.

    Плюсы Agile:
    Практически нет простоя ни у кого - все всегда могут занять себя задачами.
    В случае появления новых требований, их можно без особого вреда ввести в проект почти на любой стадии. Главное чтобы технически это было возможно (в случае waterfall проблема именно на уровне утверждений и плана, то есть бюрократии)
    Адекватное использование рабочей силы - если у кого-то нет текущих задач, его официально можно занять под другие проекты.

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

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

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

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    Во время работы основная проблема для вашего заказчика, это запрет на просмотр сайтов 18+?
    Что у вас за клиент такой?
    Ответ написан
    1 комментарий
  • Чем должны отличаться stage и prod среды?

    saboteur_kiev
    @saboteur_kiev Куратор тега Программирование
    software engineer
    Обычно test и prod не должны отличаться хардварно/софтварно, за исключением мощности.
    В богатой фирме железо/софт вообще идентичны. Если не требуется идеальное совпадение, в тесте можно иметь меньше винтов, ибо боевая база не нужна.

    Задача - на тесте полностью скопировать окружение prod, и в случае проблем, суметь воспроизвести это на нем.
    Dev должен более-менее совпадать, в основном версии софта, но это зависит от того, что там происходит.

    Опять же, сильно зависит от задачи. Если это боевой сервер, было бы например неплохо на test проверить как работают новые прошивки биоса/рейд контроллера, перед тем как повторять это на боевом.
    Если же это только небольшой сайт, то вполне достаточно будет воспроизвести версию ОС и ПО. В общем смотря что крутится.
    Ответ написан
    Комментировать
  • Какие есть инструменты для удаленного согласования бюджетов?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    большие бюджеты согласовывают приездом или по телефону.
    А инструмент, который вы хотите, это несколько странная вещь.
    Чем больше бюджет, тем меньше детализирование, и больше зарплата менеджера, который контролирует отдельную группу/проект.
    Нет смысла двум боссам согласовывать КАЖДУЮ строчку.
    Ответ написан
    5 комментариев
  • Лучшие (с точки зрения работодателя) кадровые агентства Москвы, СПб, Киева, Харькова, Минска и других городов?

    saboteur_kiev
    @saboteur_kiev Куратор тега Веб-разработка
    software engineer
    Агентства? толковых С# разработчиков?
    Агентства могут просто искать разработчиков. Собеседовать и выяснять толковость нужно специалисту в С#
    Ответ написан
    2 комментария
  • Как найти общий язык с сотрудниками военных предприятий, чтобы они дали описание своих процессов для составления ТЗ?

    saboteur_kiev
    @saboteur_kiev Куратор тега Программирование
    software engineer
    Вы аналитик, и вы даже не начали работу, а уже сразу на тостер?
    Может быть вам стоит найти другого, более опытного аналитика и поручить работу ему?

    Пообщайтесь с предыдущим аналитиком.
    Попробуйте найти и узнать какие программы уже вводились, кем, и пообщаться с ними. Если найдете вариант успешного внедрения - вот с теми людьми пообщайтесь более плотно.
    Ответ написан
    Комментировать
  • Существует ли программа полного цикла разработки приложений?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    У вас перечислено далеко не все, что нужно в полном цикле, а некоторые вещи как-то нескладно.

    Готовых программ много, но практически все они идут отдельно стоящими компонентами, которые можно интегрировать в разных комбинациях. Если мне нравится билд сервер одного производителя, а коде ревью другого, 99% что они легко интегрируются штатными средствами или официальными плагинами. И это - хорошо.
    Ответ написан
    1 комментарий
  • Ваши действия, если джуниор не успевает выполнить задачу?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    Адекватный джуниор не должен ПРОСТО сидеть и не успевать в срок.

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

    В этом заключается разница между чайником и ламером, между адекватным человеком, который со временем вырастет, и тем, за которым ВСЕГДА придется бегать.

    Лично мои действия - если Джуниор не выполнил задачу в срок и я об этом узнаю с окончанием срока - нафиг такой человек в команде (ну разве что попробовать дать еще одну задачу, чтобы убедиться что это не случайность). А если Джуниор подойдет за помощью вовремя - задача будет решена в срок.
    Ответ написан
    6 комментариев
  • Как вы боретесь с наследием кода в больших проектах?

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

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