Хочу собрать статистику по сложности задачи. На блоге премодерация, так что не удивляйтесь, что вы не увидите своего ответа. Ответы читателей будут опубликованы через неделю (если они этого пожелают). Если нет указаний - ответ не будет опубликован. Задача состоит из трех частей. Вторая и третья части высылаются принявшим участие, либо будут опубликованы позднее, как и мои варианты ответа.
Около пяти лет назад начал писать пространный документ о системе компенсации труда постоянных сотрудников в IT-шной конторе. Но в дело документ не пошел. Впоследствии у меня начали возникать сомнения в разумности того, что я придумал, и я так больше нигде и не пытался использовать эти наработки. И не публиковал их. Однако зерно истины там есть, осталось только его найти. Вот я и пробую.
(more…)
По итогам семинара было озвучено несколько тезисов. Так, в частности, есть несколько очень эффективных способов разорить предприятие:
Способ первый. Увеличить локальную эффективность отдела(ов).
Увеличение локальной эффективности отдела часто не приводит к увеличению дохода фирмы. Более того, слишком часто оно приводит фирму от состояния прибыльности к разорению.
Способ второй. Сбалансировать мощности отделов.
Цитата из Гольдрата: “настоящая причина того, что ты не можешь достичь идеального баланса [производительности отделов], намного более фундаментальна, чем те, которые ты назвал. Все остальные - относительно незначительны. На самом деле, настоящая причина в том, что чем ближе ты состоянию идеального баланса, тем ближе ты к банкротству.”
Второй метод очень эффективен для разорения предприятия. Более того. Он чудовищно эффективен. Но есть еще более сокрушительный.
Способ третий. Заставить каждого работника предприятия работать с максимальной производительностью.
Андрей Степенко говорит, что в этом случае предприятие разоряется за два производственных цикла. Я считал, что за три, но положусь на мнение эксперта.
Не буду проводить интернет-опрос, но все-таки любопытно. Какой процент фирм сейчас следует вышеперечисленным рецептам разорения?
PS. Из вышеизложенного есть исключения. Но не льстите себе. Вряд ли ваша фирма входит в их число.
Интрига
Давно размышляю о подходящем наборе ролей и о месте Отдела Технического Контроля (ОТК) в разработке программного обеспечения.
И вот начитавшись умных книжек, я понял, что мне предлагают математический аппарат, позволяющий делать расчеты на основе моделей. Как говорится, пуркуа бы и не па?
Начнем с простейшей модели, дабы понять правила игры, а потом, при необходимости, подставим реальные цифры, основанные на замерах.
Дисклаймер. Приводимых ниже моделей недостаточно для эффективного управления. Т.е. в некоторых случаях считать нужно так, в других по другому. Других случаев больше. Если вы не знаете, как отличить один случай от другого - ни в коем случае не используйте эти модели для воплощения в жизнь. Иначе будет как с применением рефакторинга, только хуже.
(more…)
Японская компания, переживающая тяжелые времена, предпринимает такие шаги:
взято из “Новая экономика” Э. Деминга и “Сделано в Японии” Акио Марито.
Наши компании, переживающие тяжелые времена, поступают немного иначе. Да, я понимаю, почему Япония добилась таких высот. И почему их сотрудники преданы компании. Но вот что мне интересно: зачем вместо попыток выхода из кризиса наши компании стараются как можно быстрее избавиться от своего главного актива? Кризис - это замечательный повод встряхнуться, оглядеться и сменить неэффективное управление. Придумать новые продукты, выйти на новые рынки или создать их. Придумать новые технологии или усовершенствовать существующие.
И еще мне интересно. Какой преданности от сотрудников ожидают компании, если они этих самых сотрудников увольняют с циничным: “Это бизнес!” - при первом же чихе на рынке? Возможно, они ожидают, что и после кризиса лояльность и мотивация сотрудников будет необыкновенно высокой?
Мне в детстве мама выколола глазки,
Чтоб я в шкафу варенье не нашел.
Я не хожу в кино и не читаю сказки,
Зато я нюхаю и слышу хорошо!
Можно сколько угодно говорить, что на написание нормальных требований к системе нет времени и необходимой квалификации. Но вот на то, чтобы получившуюся жертву генетического эксперимента доводить до ума, и время, и люди находятся. Много, много времени.
Пусть мы не ходим в кино и не читаем сказки, в смысле потратим немного времени на переделывание, но зато мы нюхаем и слышим хорошо, то бишь сэкономили кучу времени на написание ТЗ.
Что есть тестирование? Это процесс проверки ПО на соответствие спецификации. Нет ножек, т.е спецификации - нет варенья, т.е тестирования.
И более того. Нет ножек - нет разработки.
В принципе, существуют проекты, в которых можно сэкономить на спецификации. Крошечные такие проекты, юзкейсов на 5-10. Наверное, есть команды которые могут эту экономию получить даже на 50-ти юзкейсном проекте. Но вы с такими командами вряд ли встретитесь.
Фантастика, господа, на втором этаже.
“Word на моем домашнем компьютере не знает слово «командообразование». Оно пришло к нам совсем недавно вместе с явлением, которое обозначает. Конечно же, это калька с английского «teambuilding». Однако и для Запада это явление в новинку.”
Теперь и я узнал, что командообразование для нас в новинку. А я то последние лет 5-10 мучался вопросом, ну почему никто не хочет заниматься командообразованием? Теперь понимаю. Нужно было сначала полностью похоронить нашу культуру командообразования, чтобы потом тянуть ее с запада. Ну ничего, глядишь еще лет через 25 запад дорастет до того, что у нас было четверть века назад…
Чтобы не быть голословным, термины “песок-мягкая глина-мерцающий маяк-…-…” ни о чем не говорят? А практики для прохождения по этим ступеням изучали? Пробовали? Сколько сотен (ладно, пусть десятков)? Какие именно? У туриков были свои методы, у КСП-шников - свои, у коммунаров - свои. Они все прекрасно работают.
Нет? Уже никто не помнит? Ну тогда действительно нужно ориентироваться на запад.
“Процесс - это жизнь, результат - это смерть!”
Ищу работодателя, для которого понятие “работа” - это то, что нужно сделать. Хочется посмотреть, а как у них там? Похоже таких мало. Пока мне встречался только один тип работодателя. Для которого “работа - это место, куда нужно ходить”.
Наш российский принцип:
1) надо 5 аналитиков (техписов/ программеров / ПМ)
2) надо автоматизацию тестирования
3) надо стимулировать коллектив плакатами и цветовой дифференциацией бейджиков!!!
Это все не надо. Надо достигать результата. А одного и того же результата можно достигать, как наняв 5 аналитиков за 2000-2500$, так и просто заплатив аутсорсеру 15000-20000$. Второе выгоднее. Или платя одному хорошему аналитику приличную зарплату в 7-10$ тысяч (еще выгодней).
Короче. Вам шашечки или ехать? Пока всем нужны шашечки.
PS. Хотя может я перфекционист?
Здесь я привожу вопросы, которые я задаю кандидату на позицию технического писателя практически в обязательном порядке. При создании этого списка я исходил из того, что технический писатель должен обладать знаниями и навыками:
Буквально недавно меня попросили провести собеседование с претендентом на позицию аналитика. Хорошо, что вопросы были сформулированы давно. Эта заметка в помощь остальным, проводящим подобные собеседования. Важно, почему и зачем мы задаем именно эти вопросы. Как только это станет понятно, можно будет придумать другие вопросы. А главное, понять, что должен отвечать кандидат.
Основные виды деятельности аналитика:
Это основные виды деятельности. Гипертрофируем в утверждение: “Эти виды деятельности есть смысл существования проектной роли аналитик”. Дополнительно, в зависимости от проекта, аналитик может заниматься внедрением, подготовкой рабочей и конечной документации, тестированием, подготовкой документов, в соответствии с ГОСТами. Оставим пока эти вещи в стороне и сосредоточимся на первостепенных.
You are currently browsing the archives for the Управление проектами category.