Рубрика «управление проектами» - 369

Piccy.info - Free Image HostingИстория развития методологий проектирования (программной инженерии)

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

С чего все начиналось

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

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

Сам проект был посвящен большой и объемной фиче в уже существующем продукте, но не являлся r&d проектом, где подобный разброс можно было бы правдоподобно вписать в проектный план.

И в то время, как финансовый отдел уже расчехлил пулемет, наша проектная gang of four собралась на срочное обсуждение того, что делать с такими сроками разработки: можно ли планировать загрузку людей, считать риски, как быть с критическими взаимосвязями с другими компонентами. Но, пожалуй, самым волнующим вопросом был вопрос насколько валидна такая оценка, и можем ли мы помочь разработке оценивать точнее и лучше.
Читать полностью »

Продолжение перевода серии статей «5 уроков просмотра стартапов»,
прошлая статья Настоящие нечестные конкурентные преимущества

На сотнях стартап питчей в Capital Factory, не нашелся и десяток людей, которые были бы готовы сказать «если вы создадите этот продукт, я дам вам X долларов».

Да, но кто сказал, что они купят это?

Задумайся над этим: сотни людей готовы уволиться с постоянной работы, потратить свои сбережения, рискнуть личной репутацией, трудиться 70 часов в неделю, пережить такой же стресс, как и рождение ребенка (поверьте мне, я испытал рождение и ребенка, и стартапов)… и все это при том, что нет жалкого десятка людей, действительно готовых заплатить за то, что предлагают стартаперы.

Недальновидно, не правда ли?
Читать полностью »

Хочу поделиться своим опытом и наблюдениями, которые следует взять на вооружение и не отступать им каждому самураю project-менеджеру. Ведь известно, что project-менеджер это ключевая фигура в любом проекте. Он должен взаимодействовать как с Заказчиком так и с командой разработчиков.

Совершенствуйте свои знания

Невозможно знать абсолютно все! Встречаются проекты, для выполнения которых, просто необходимо почерпнуть знания из различных источников. Провести не один день за литературой и просмотреть не один час интерактивов, что бы понимать в итоге, что от вас хочет Заказчик и как эти требования донести на понятном языке до разработчиков.
Помните! Если вы будете иметь только общее представление о работе своих подчиненных, то они в итоге получат либо (в лучшем случае) «надзирателя», который будет всегда полагаться только на их честность, либо (в худшем случае) «нахлебника», которому будут «вешать лапшу на уши» вся команда и проект будет, мягко говоря, отставать от графика.

Ваша команда

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

Протагонист, кажется, поймал удачу за рога и бодро шагает к светлому будущемуМы продолжаем публикацию героического эпоса о том, как в одной маленькой, но очень перспективной организации работал Проектный офис и внедрялась MIS, Management Information System. Из предыдущей руны вы узнали, как главный герой, РПО, получил в своё ведение методологическое обеспечение проектной деятельности, как он начал свою работу, с какими первыми проблемами столкнулся, и как с ним впервые обошёлся призванный на княжение варяг, СЕО.

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

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

Как это вам надо две недели на эту задачу? Что, правда? Вот на эту элементарную формочку с тремя полями и двумя кнопками? Две недели? Да вы надо мной издеваетесь, наверное! Давайте разбираться.

Как две недели ?!Что? Нужна ли валидация данных при вводе? Ну, конечно, нужна! И вообще, вот это поле лучше разбить на два, так понятнее. А вот в это добавить маску. А вот это — заменить на выпадающий список. Где брать варианты для этого списка? В базе на сервере, конечно. Как это их там нет? А, ну да, это же в другом проекте они у нас были… Ну, значит надо добавить. Взять там и добавить сюда. Сейчас я дам вам контакт разработчика того проекта — обсудите с ним. Он, правда, у нас уже не работает, но я думаю, вполне можно спросить что и как — он расскажет, скорее всего.

Мы всё обсудили? Нет? Что ещё?
Читать полностью »

Недавно, на Скрам портале была опубликована статья Майка Кона об Общепринятых практиках в Скраме — практиках, которые довольно часто встречаются в Скрам-проектах, но не являются базовыми правилами Скрам.

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

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

Я ни в коем случае не претендую на полноту практик и буду рад услышать дополнения. Некоторые из перечисленных практик заслуживают отдельных статей — это work in progress.

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

В продолжении темы, почему иногда нужно делать свой велосипед, хочу дополнить и расширить эти мысли причинами, по которым этого делать не стоит.

Почему иногда не стоит изобретать велосипед

Причина 1. Вы не знаете, как такие велосипеды устроены

Посмотрите внимательно на предыдущий топик. Генри Форд — с детства изучал технику. Его сестра как-то сказала, что в детстве любую игрушку старались спрятать от него, потому что он ее тотчас разберет на винтики. Работал инженером в «Электрической компании Эдисона», был совладельцем «Детройтской автомобильной компании». Он точно знал, что такое — автомобиль. Он точно знал технические нюансы. Он точно знал. что черная краска сохнет два дня, а любая другая — две недели! Ну не из-за прихоти же он однажды сказал, что автомобиль будет только черным.

Игорь Сысоев, прежде чем делать свой nginx, уже имел «достаточно неплохой опыт работы с Apache — и как у системного администратора, и как у программиста».

Знаете ли вы, что вам предстоит на пути создания своего велосипеда? Или просто готовы окунуться с головой, не проверив глубину водоема?

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

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

Переведено в Alconost Translations. Часть 1 — habrahabr.ru/company/alconost/blog/170201/

7. Презентуйте и обсуждайте документы, а не слайд-шоу

В интервью Чарли Роузу Безос говорит: «Обычно на корпоративном собрании кто-то один выходит вперед и представляет общему вниманию… что-то вроде слайд-шоу. С нашей точки зрения… таким образом вы получаете очень мало информации, вместо нее вам достаются только тезисы. Это облегчает задачу тому, кто проводит презентацию, но усложняет понимание тем, кто его слушает. Поэтому вместо этого мы на всех наших собраниях рассматриваем подготовленный заранее документ — 6-страничную повествовательную записку. И вот, когда вам приходится выписывать свои идеи в виде законченных предложений и полновесных абзацев, это заставляет вас думать яснее и четче».

image

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

Как стать ведущим разработчиком. Часть 2Продолжение перевода статьи Джона Оллспоу о личных качествах ведущих разработчиков.

Зрелые разработчики не жалуются просто так

Вместо этого они рассуждают, основываясь на наблюдениях, и предлагают варианты решения найденной ими проблемы. Один опытный менеджер сказал мне: «Никогда не приходи к своему начальнику с жалобами, если у тебя нет готового решения проблемы. И лучше, если решений будет несколько». Но даже если у вас не получилось найти ни одного решения — это уже лучше, чем жаловаться просто так.
Читать полностью »


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