А вот новость, которая, в отличии от покупки борланда микрофокусом, интересна не только как источник ностальгии, воспоминаний и рассуждений на тему sic transit gloria mundi. VMWare покупает SpringSource. За 400 примерно миллионов, если кому интересно. Род Джонсон подробно пишет об этом в своём блоге. CTO VMWare Стив Херрод тоже пишет, еще более подробно. Создавать совместно будут "PaaS с человеческим лицом".

Микрофокус довольно резво приступил к освоению доставшихся ему активов. На сайте размещено обращение к пользователям Borland с которого большинство ссылок, относящихся к продуктам, ведут на странички уже микрофокусового дизайна. Together, StarTeam и BMS пока не доделали и ссылки ведут на ошмётки борландовского сайта но при этом битых ссылок вроде нет кое где ссылки с ошмётков ведут обратно на микрофокус. Work in progress, короче.

Что касается доставшихся микрофокусу людей, то их, к сожалению, сокращают. Усреднённая цель, похоже, 30%, но некоторые офисы вырезают под корень. Так что, ничего кроме поддержки приобретённых продуктов, включая Together, ожидать не стоит.

Торги закончены, Микрофокус победил. Цена в итоге - полтора бакса за акцию. Если попробовать пойти на www.borland.com - попадаешь на www.microfocus.com. Судьбу питерского и пражского офиса, говорят, обещали решить "в ближайшее время".

Прощай, Борланд!

Данный текст скопирован из комментария к обсуждению вот тут. Само обсуждение довольно интересное, рекомендую.

Если поговорить с преподавателями различных кафедр/ВУЗов, то одна из немногих вещей, в которой они сходятся - студенты стали слабее. Студенты хотят учиться меньше чем раньше, но даже те, которые хотят, могут меньше чем раньше. Это говорится хорошими преподавателями из хороших университетов, не рассказчиками анекдотов и не прогульщиками своих лекций. И это относится к студентам и младших и старших курсов.

Я заканчивал 239-ю школу в 1987 году, тогда же и поступал в ВУЗ. Меньше всего 239-я школа 1987-го года походила на детский сад. Последнее, чем занимался мой преподаватель математики Владимир Васильевич Бакрылов - это "пытался заинтересовать тех, кто ничего не делает". Те, кто ничего не делал, из школы вылетали.

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

Ситуация последних лет, при который не студент/программист делал все от него зависящее, чтобы поступить/удержаться в ВУЗе/компании, а ВУЗы/компании были вынуждены за студентов конкурировать, крайне негативно сказалось на среднем уровне и студентов и программистов. И у тех и у других сформировалась уверенность, что им должны больше, чем они должны. Это уверенность мало совместима со взрослой жизнью - тут я на 100% согласен с Николаем Михайловичем. После августа 2008 программисты это начали осознавать. И осмелюсь предположить, что довольно скоро ситуация распространиться "вниз по кластеру". То есть, например, в АФТУ с его индивидуальным подходом и высококлассными преподавателями будет *не поступить* студенту, который до магистратуры не понял, кому в точности нужно, чтобы он учился.

В бытность мою директором питерского Борланда руководил мною, как-то, индус Радж Шинде. Человек он был неплохой, но не без особенностей. Не любил, например, выражать мысли прямо. Ещё рекомендовал всем читать жульническую книгу In Search of Excellence. Ну, Восток - есть Восток. Как-то обсуждали с ним бюджет на какой-то эвент - новый год, вроде. Мы перед этим с главным нашим бухгалтером все тщательно посчитали, ужали где можно по максимуму, вышло 10 что-ли тысяч баксов. Докладываю Раджу. Сделай, говорит, за 5. Я начинаю рассказывать, почему 10, и почему за 5 не очень получится. Да нет, говорит, ты мне не рассказывай, ты сделай за 5 - и все. Ну, я напористый был директор - убедил. В конце говорю, в следующий раз, говорю, я перед тем как тебе цифру говорить - умножу ее на два. Раз уж ты, вместо того, чтобы слушать аргументы, на два делишь. А он мне отвечает - я, говорит, уверен, что ты так и сделал в этот раз.

Базарный вот этот подход, к оценкам, коммитментам как к предмету торга, очень распространён. Приходит программист к менеджеру, рассказывает результат оценки, а тот ему - сделай в два раза быстрее. Мифы разные по этому поводу гуляют - что надо умножать на два, потому, что поделят на два (как показывает вышеприведённый пример, не такие уж и мифы). Я ещё могу понять (с трудом) когда торговлю разводят по поводу зарплаты при приёме на работу. Сейчас, например, на питерском рынке труда принято предлагать кандидату зарплату на 20% меньше, чем он попросит. Кандидаты соглашаются, говорят. Но торговля по поводу результатов оценки имеет примерно столько же смысла, сколько спор о результате умножения 2 на 2.

Мотивация опытного менеджера, пытающегося выбить оверкоммитмент, понятна. Она является частным случаем стратегии получения большего надоя с коровы при понижении расходов на корм. Известно, что программисты, особенно молодые, склонны с большой ответственностью относится к своим коммитментам, и даже если коммитмент выбит с паяльником, работать по 80 часов в неделю, за ту же зарплату, чтобы с ним встретится. К сожалению, программисты или менеджеры первого уровня также склонны включаться в торговлю. Я как-то слышал советы сходить на рынок и потренироваться, чтобы лучше торговаться при обсуждении оценок. Я бы посоветовал, вместо этого, относится к процессу оценки серьёзно и добиваться уверенности в своей оценке, как в аксиоме. Обсуждать можно соотношение между агрессивностью сроков и риском, но не результат оценки. Хорошая новость заключается в том, что в большинстве случаев, если удаётся направить дискуссию в правильное русло, вышестоящий менеджер соглашается с аргументами и вы приступаете к проекту с реалистичными коммитментами.

Один из признаков хорошего менеджера проектов - умение минимизировать число сюрпризов. Один из основных источников сюрпризов - неявные допущения, сделанные при планировании. Assumptions. Допущения делаются всегда и сами по себе они не ведут к сюрпризам. Проблемы с допущениями возникают от того, что они неявные.
Возьмём, например, простое утверждение. "У нас есть команда из 4 разработчиков и мы оценили объем разработки в 12 человеко-месяцев. Мы обещаем заказчику, что продукт будет готов через 3 месяца". ( Сколько в этом утверждении скрыто неявных допущений? )

Немало постов в этом журнале навеяно чтением журнала yakov_sirotkin. Думаю, пришла пора посвятить отдельный пост этому феноменальному явлению. Журнал Якова играет для IT-тусовки ту-же роль, которую для всего ЖЖ-сообщества играет журнал tema. То есть, на самом деле, совершенно не важно, напишет ли Яков очередной совет CEO, банальность про рефакторинг, продолжение драматичной истории про Васю и Петю и их нелёгкие карьеры или вообще про домашние роды. В комментах обязательно собирается интересная тусовка, и читать их, как правило, значительно интереснее, чем оригинальный пост (не в обиду Яще будет сказано).

Мне кажется, Якову надо откликнуться на вызов времени, и продолжать двигаться по пути tema. То есть, конечно сиськи размещать по субботам не надо, это будет совершенно не в стиле журнала Якова. Но зачем, например, ограничивать себя рефакторингом? Почему не написать несколько постов про оператор if? Я уже не говорю, про оператор goto - какие дискуссии мог бы породить такой пост!

А то, заходишь в ЖЖ утром, а поста Якова нет, и дискуссии в комментах нет - сразу настроение портится.

Дерзай, Яша, мы ждём новых интересных постов! -)

MicroFocus поднял цену. Мифический "неназванный финансовый покупатель" так и остался неназванным и вышел из игры. Возникает вопрос, а был ли мальчик? Или МикроФокус просто развели на несколько лишних миллионов -).

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

( примеры из жизни )

Тут, конечно, следует учитывать специфику моего опыта. Львинная его доля - даже во времена SwiftTeams-а пришлась на ресерч проекты и изготовление собственных продуктов. Где предсказуемость была гораздо менее важна, чем инновации и гибкость. Там, где работа была скорее работой на заказ, и где требовалась именно предсказуемость и "встреча с ожиданиями" (как перевести meet expectations?), все делалось по правилам гораздо чаще и отклонение от них заканчивалось хуже.

Раскопал вот.... На дворе 1996 год и Питер Коад только что получил первый Jolt Cola за Together расширение для Borland C++. Никто еще не знает что часть людей с этой картинки в Borland-е будут работать, а другая часть примет активнейшее участие в отодвигании продукта JBuilder на вторые роли на рынке.