Commited: 50+ воркшопів з ТОПами тестування: M.Bolton, G.Bahmutov, T.King, R.Desyatnikov, J.Bach. Лише за $40 на рік та економія $15 до 20 квітня
×Закрыть
  • Увлечение Agile может быть вредно для вашего стартапа

    даже «старый» RUP в этом плане интереснее, потому что вначале определено, что должно быть в итоге. в скраме пытаются угодить всем, изобрести абсолютно гибкий звездолет, в итоге — получается мопед, а клиенту нужен был автомобиль. главное — ездит...

    Поддержал: Ljt
  • Увлечение Agile может быть вредно для вашего стартапа

    Надеюсь, вы не считаете, что предсказуемость может быть обеспечена только по Scrum ))) Есть и другие методологии, даже более эффективные на предмет предсказуемости.

  • Увлечение Agile может быть вредно для вашего стартапа

    Аджайл хорошо работает для product management — один продукт в компании, все стабильно и понятно, только выпускаем для него апдейты. Но это когда все уже `on track`.
    Что касается стартапов, бороться с неопределенностью в начале проекта аджайл помогает мало. Тут можно посмотреть в сторону строгих унифицированных процессов типа RUP.
    Потом, если у вас fixed-price проект — аджайл опять-таки неэффективен. При time&material аджайл более интересен.

    Просто молиться на аджайл, скрам (как это у нас любят) — бессмысленно.

  • Простой путь

    аджайл вообще малоэффективен по поводу оценок

  • Простой путь

    PMBOK (например) описывает методики оценки (parametric, three-point-estimate, .... etc), поэтому можно не изобретать велосипед.

    Есть такая штука — ROM, ее используют в начале проекта для получения «грубой» оценки. Т.е. тот же ПМ может это сделать. Но когда мы говорим о точных оценках, после уточнения требований, оценивают (что логично) разработчики. ПМ может дополнительно закладывать свои оценки на проджект менеджмент — риски, коммуникации, планирование. QA — на качество. .... etc. Т.е. каждый оценивает СВОИ задачи в проекте.

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

    Для этого и придуманы инструменты, помогающие снизить риск недо-, пере-оценки.

    Человеку свойственно ошибаться, и девелоперу тоже. Статистический анализ — это круто, но главное, чтоб оценивал тот, кто будет выполнять задачу. Если, например, разработчик перекладывает свои задачи оценки на ПМа, то, наверное, он что-то неверно понимает. А Макконнелла всем полезно читать (и не только о программировании).

  • Само собой

    «Самоорганизующиеся команды» — научная фантастика в IT (конек скрам-проповедников). Но мечтать никто не запрещает... А вообще очень напоминает анархию.

  • Логика заказчиков и программистов, том первый

    интересный пост

  • Зарплаты программистов — декабрь 2011

    так у нас же все знают английский — куда не плюнь («а хули его учить — это же не джава»)
    только знать можно по-разному
    уровень окончания большинства курсов — не выше среднего

    но считают себя знатоками млин

  • Корпоративы — это хорошо или плохо? Да и нужны ли они в принципе?

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

  • Тарас Кицмей, SoftServe: к 2015 году ІТ догонит металлургов

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

    зачем? наверное, затем, что для успешных проектов, приносящих прибыль, одних только программистов недостаточно — сам по себе код ничего не стоит

    Поддержал: Alex Orlov
  • Наскільки безпечно відвідувати співбесіди?

    кому-кому, а разработчикам сейчас нечего бояться — для них сейчас золотое время
    они требуются сотнями, и, скорее, они выбирают, а не их выбирают

    переживать надо другим айтишникам, и то — не всегда

  • На «собеседовании» в Мрія Агрохолдінг прождал манагера 45 минут

    Иногда так поступают, чтобы специально погрузить кандидата в состояние стресса (у нас не умеют проводить такие собеседования, но многие пытаются). Но при нынешнем дефиците разработчиков, сейчас на такое вряд ли кто решится. Это либо очень уверенная в себе компания, либо иди.отизм/бардак... Во второе верится больше.

    Поддержал: Eugene Svirskiy
  • Компания Magento запускает сертификацию для разработчиков

    Zend уже не в моде?
    В принципе, сертификацию можно сделать для чего угодно.

    Но в данном случае это скорее актуально для разработчиков, работающих в Magento, чем для всех.

  • Почему мы выключили отзывы о компаниях на ДОУ и когда мы включим их снова

    Вариант 3. Кому-то очень не хочется читать негативные комменты о себе. Поэтому хотят знать «врагов» в лицо )

  • Карта карьеры

    Еще в 90-е в нашей стране только начали появляться IT компании, и руководителей выбирали скорее по количеству лет опыта работы программистом, чем по наличию необходимых качеств (и уж тем более образования) — т.н. «старая школа». Может быть, это было обусловлено тем, что тогда просто не из кого было выбирать. Не было еще четкого разделения по специализациям, да и вообще, всё только начиналось. Традиция сохранилась и по сей день во многих компаниях.

    Опыт помогает, по пунктам а), б), в) согласен абсолютно.

    Но время изменилось, ведь успех проекта сегодня обеспечивают далеко не только разработчики, на первое место в профессии ПМа выходят коммуникации и customer service (особенно в аутсорсе), — что чаще гораздо важнее technical skills.

    Не знаю, причем здесь Гарвард (HBS ? :)), но я имел ввиду другое:

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

  • Карта карьеры

    Основы программирования и баз данных, понимание ключевых технологий (совершенно необязательно знать их досконально) — может, это утрировано, но больше не надо, плюс желание и возможность самостоятельно повышать свой уровень знаний технологий и пр. Раз в несколько месяцев появляются новые технологии, ПМ всегда будет отставать от них, и отстанет навсегда, т.к. в менеджменте своей «техники» достаточно.

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

    О каких правилах речь? Кто их придумал, утвердил? Лично вы? :)

    Мне кажется, вы склонны считать исключением все, что отличается от вашего опыта )) Так можно вообще любой пример считать исключением ))

  • Карта карьеры

    Не знаю, где в моих комментах вы нашли TW )), но я имел ввиду людей, которые могут приходить вообще не из IT сферы. ИМХО они даже лучше справляются с работой ПМа, чем «отягощенные бэкграундом», т.к. вносят свежий взгляд на решение обыденных проблем (конечно, еще есть компании, в которых считается, что основные задачи Пма — это ревью кода, архитектура, паттерны, тестирование и пр. — тут либо фундамент конторы шатается, и экономят на всем, либо неправильно называется должность). У них нет «запасного аэродрома» («а вдруг не справлюсь, то вернусь к работе девелопера/тестировщика/....») - т.е. рисков в карьере больше, поэтому и более ответственно относятся к своей работе. Т.е. думать как менеджер они начинают гораздо быстрее :)) И менторинг здесь будет только помогать. И я только за, чтоб такие люди приходили в IT.

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

    Насчет имен, — их много. К примеру, недавно на DOU было интервью с Лилией Вершининой. Лично с ней незнаком, к сожалению.

  • Карта карьеры

    Такие люди и в циклуме есть :)) присмотритесь ))
    Ну а по поводу учить, так это вы же пытаетесь учить — кому, как, и куда расти ))

    Успешная карьера может складываться совершенно по-разному.

  • Карта карьеры

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

  • Сколько денег вы хотите?

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

← Сtrl 123 Ctrl →