31

Идеи и мозговой штурм / Re: Чего боятся Аналитики сейчас?

« : 06 Августа 2009, 01:03:50 »

1) Аналитика можно уволить, и первые полгода-год это вряд ли сильно отразится на продажах ПО. Его работа (в отличие от работы программистов и тестировщиков) имеет некоторую инерцию, как и работа, например, сотрудников маркетинга и PR. Обычно у аналитика готовы - и вполне от него отчуждаемы - долгосрочные концепции продуктов, общий roadmap на пару лет вперёд, подробные ТЗ на пару следующих итераций. А ошибки править и не очень сложные доработки делать программисты могут вообще безо всяких аналитиков.

Многие руководители и в "тучные" времена были временщиками, и едва терпели работу, направленную на перспективу. А сейчас временщиками стали почти все, живут по Гайдару "нам бы день простоять, да ночь продержаться".

Я знаю 2 (!) компании только в нашей не слишком широкой отрасли, которые практически разогнали даже программистов с тестировщиками, но продолжают продавать своё ПО, и даже тех. поддержку и "фьючерсы" по нему.

Но самое ценное - это люди. Поэтому когда кризис кончится - он кончится не для всех.

2) Аналитику может стать нечего делать, т.к. в условиях "кризиса" многие сокращают программистов и тестировщиков (а первыми зачастую сами уходят самые сильные). В результате разработка сводится к мелким доработкам и правке ошибок.

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

32

Бизнес-анализ и Целеполагание / Re: Анализ рабочих процессов в начале деятельности компании

« : 31 Июля 2009, 10:48:37 »

<...> Мысль о том, что  преследует меня уже давно и неотступно. Осталось только добиться назначения конкретного специалиста, который будет налаживать неавтоматизированные процессы...

Назначение в группе из 5 человек? IMHO просто начните это делать сами. Убеждайте, демонстрируйте на своём примере, работайте, оценивайте результаты работы (в $), показывайте, что с хорошими процессами лучше.

33

ПО Аналитика / Re: Telelogic System Architect. Впечатления от знакомства

« : 31 Июля 2009, 10:21:46 »

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

Полностью согласен. К тому же, есть ещё принцип KISS. Переусложнённые процессы и инструменты, а также сложные люди , обычно хуже работают и чаще ломаются.

34

Обсуждение статей / Re: Канбан в IT (Kanban Development)

« : 29 Июля 2009, 11:59:12 »

Коллеги, а как применять Kanban и Scrum в больших проектах с фиксированной стоимостью и реально ли это вообще?<...>

Да, вполне реально, но сложно. Сначала производится сбор требований, проектирование архитектуры, оценка трудоёмкости и планирование "в общем". Затем проект разделяется на подпроекты. На подпроекты выделяются SCRUM-команды, максимум по 5-6 чел, и уже ПМ, аналитик и архитектор являются для них product owner'ами.

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

Я это видел "в живую", это работало, хотя и с проблемами. IMHO они заключались в:

• Недостаточном предварительном проектировании и планирования. SCRUM-группы начали свою работу существенно раньше, чем все договорились, что же надо сделать "в большом". В результате, ответ на вопрос "что надо делать" сильно искажало то, что что-то уже сделали, не хочется переделывать.
• Систематическом нарушении правил SCRUM.

35

Обсуждение статей / Re: Канбан в IT (Kanban Development)

« : 22 Июля 2009, 00:58:53 »

Попробую на следующей итерации одного из продуктов использовать "IT-канбан" для оперативного контроля внутренней команды, совмещая с "классическим" планированием.

----

В описанном в статье виде, в "IT-канбан" есть те же проблемы, что и в SCRUM: невозможно оценить продолжительность, трудозатраты, цену выдачи, непонятно, в каком состоянии находится проект, сколько (времени, денег, трудозатрат) осталось до выдачи. В таком виде "продать" выдачу инвестору сложно.

Выдавать результаты каждой отдельной задачи? Тоже не очень эффективно, тем более что результаты далеко не всех задач обладают самостоятельной ценностью. И тут возникает вторая проблема: задачи связаны между собой, они могут объединяться и дробиться, причём одни части могут пойти в один столбец доски, другие - в другой.

Тут же становится видна третья проблема: некоторые задачи удобнее выполнять в "пакетном" режиме. Например - согласование и приёмочное тестирование.

Чтобы оставаться на нужном уровне абстракции и количества задач, наверное, в "IT-канбане" имеют смысл только большие и длинные задачи, которых десятки, а не тысячи. Иначе они не поместятся на одной доске. И тут же натыкаемся на четвёртую проблему - внутреннее противоречие: цель "IT-канбана" - в том, чтобы незавершённых задач было как можно меньше, а приходится делать их длинными. И это противоречие граничит с границами применимости "IT-канбана", да и просто agile: небольшие проекты и короткие, не подразумевающие НИР задачи.

Опять же, доверие исполнителям, "всё равно при обычном менеджменте существует только иллюзия контроля". Это при плохом менеджменте. Исполнители бывают разными, и их цели - в т.ч. благие сами по себе цели повышения квалификации и самореализации - могут идти в разрез с проектом. Внутренняя мотивация? Интересных задач на всех не хватает, а получать удовольствие от хорошо сделанной рутины умеют не все. Средней демотивированности рядовой программист на зарплате? "Работа стоит, а срок идёт". Средней ответственности внешний исполнитель? "Ничего, до сдачи работы ещё целая ночь". Возможно, дробить задачи до размера 4-8 часов рабочего времени, и спрашивать о них каждый день - это микроконтроль, но это иногда необходимо. И тут же получается, что даже в небольшом проекте задач - многие сотни, и доска "IT-канбана" для них неудобна.

Кстати, в столбцах доски задач "IT-канбана" нет ячеек с именами людей, не ведётся статистика выполнения задач, не накапливаются исторические данные для будущей оценки и планирования, не видно, что нагрузка ложится на исполнителей неравномерно.

Как и scrum, "IT-канбан" не учитывает выгоды от специализации. Разные люди решают проблемы с разной эффективностью. То, что кто-то по своей воле берётся за задачу, не говорит о том, что он являются самым эффективным её исполнителем. Кстати, к вопросу о том, что повышении квалификации и самореализация могут быть вредными.

----

В общем, IMHO такой "IT-канбан", как и scrum в более-менее чистом виде, похож на очень быстрый и живой бег по сильно пересечённой местности без карты и компаса. Цель известна (но не видна), бежать приятно (пока силы есть), а результат... зависит от везения, количества сил, умения бегать и сложности местности.

36

Обсуждение статей / Re: Что такое недовольный клиент

« : 12 Июля 2009, 11:48:07 »

Недовольство бывает разным. Примерно в трети случаев оно не имеет отношения к качеству продукта или поддержки.

В некоторых компаниях специально работают в стиле "вечно недоволен" - чтобы "отжимать" поставщиков и интеграторов по цене. С такими лучше не работать - ещё и должен останешься.

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

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

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

----

При этом, бесспорно, бывает, когда клиенту просто "больно" из-за плохого качества или недостатка функциональности. И кстати, когда "невыносимо больно", клиенты зачастую просто молчат, их нужно спрашивать самим.

37

Сообщество Аналитиков / Re: Форма регистрации новых членов Сообщества Аналитиков

« : 07 Июля 2009, 22:21:59 »

IMHO слишком много полей со звёздочками. Логина и пароля было бы достаточно. Логин мог бы использоваться в качестве временного ника, если ник не настроен отдельно.
----
Хотя меня вообще всегда раздражает необходимость регистрироваться, особенно рассказывать о себе то, что вовсе неважно для работы системы, где-то что-то подтверждать и т.д.  Вообще, IMHO все эти регистрации на форумах - от отсутствия нормальных модулей очистки сообщений от мата и рекламы, и блокирования соответствующих паталогических личностей.

А на корпоративных сайтах - от неуёмного желания достать человека хоть из-под земли и попытаться что-нибудь ему впарить, и от отсутствия модулей, автоматически "пробивающим" человека. Google или Yandex до этого, например, остался маленький шажок... а может, они уже это умеют.

Так что если человек пришёл на сайт, например, с Google - почему бы Google не сообщить сайту, кто он, а сайту - не задавать этому человеку глупых вопросов (а подшить посещение в дело этого человека )?

38

О Сайте и Форуме / Re: [ИДЕЯ] База знаний, наполняемая посетителями

« : 07 Июля 2009, 19:24:38 »

IMHO:

1) [обще]доступная wiki
----
2) возможность голосовать за отдельные посты на форуме, повышая их релевантность (? в зависимости от статуса на форуме) при общем поиске
3) поиск с сортировкой результатов с учётом этой релевантности.

Хотя тоже, при отображении отдельных постов они будут вырываться из контекста...

39

Работа / Re: Головоломки (логические) на собеседовании

« : 05 Июля 2009, 11:12:53 »

<...> А вот если программист начинает думать о практической пользе - его надо посадить в тестирование или анализ.
Но кто же тогда будет писать идеальный код?

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

К тому же, при распределённой разработке удалённым программистам, работающим на договорной основе по сдельно-прогрессивной схеме, индивидуально или в командах по 2-3 человека без выделенных аналитиков и тестировщиков, такое знание просто необходимо: там каждый, по крайней мере отчасти, сам себе аналитик и тестировщик, и к тому же, когда он делает не то, о чём договорились, это бьёт его по карману.

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

40

Проектирование / Re: Роль архитектора в различных методологиях: как лучше?

« : 02 Июля 2009, 10:00:21 »

В наших проектах не было того, кого называли архитектором.
А вот проекты тем не менее успешно были.
Такие примеры считаются?..

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

41

Sparx / Re: проектирование БД в Enterprise Architect

« : 01 Июля 2009, 18:27:55 »

Да, медленно. Про приемлемость - нормально, моделировали, привыкнуть к этому можно. Конечно, в Power Designer удобнее. Но есть разница в цене на 2 (!) порядка:

• Sparx Systems Enterprise Architect - 4-5 тыс. руб. за рабочее место
• Sybase PowerDesigner Studio - 220-450 тыс. руб. за рабочее место

42

Проектирование / Re: Роль архитектора в различных методологиях: как лучше?

« : 01 Июля 2009, 10:51:22 »

Хочется всё-таки вернуть дискуссию в рамки "что делал тот, кого называли архитектором, в известных Вам успешных проектах".

43

Работа / Re: Поощрения

« : 01 Июля 2009, 10:40:02 »

Я бы добавил:
- долевое участие в компании и прибыли, сразу или опционом
- назначение руководителем направления, центром компетенции
- назначение на новый (причём интересный) проект
- выдача бюджета на помощников, аутсорсинг
- свободный график
- удобное рабочее место, хороший компьютер/ноутбук, мониторов - столько, сколько нужно
- бюджет (и по времени, и по деньгам, и по людям) на образование и R&D
- разгрузка от рутины и несвойственных задач
- длинный отпуск в удобное время.

И ещё, слово "возможность" я бы уточнил везде как "реализация возможности". Пока "возможность есть, но только на бумаге" - IMHO она слабо мотивирует.

44

Работа / Re: Головоломки (логические) на собеседовани&

« : 30 Июня 2009, 00:18:41 »

а по проще нельзя писать? ну и русским больше пользоваться?

а как же рост в глазах общественности? и вес на весах истории?

Застыдили совсем. Ну не было времени короче и проще изложить свои мысли. Что ж теперь, совсем молчать    ?

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

45

Работа / Re: Головоломки (логические) на собеседовани&

« : 28 Июня 2009, 15:27:26 »

Я согласен с Денисом Бесковым.

То, что человек успешно решает развлекательные головоломки, означает, что человек:

• умеет решать головоломки
• любит решать головоломки
• помнит, как решить много разных развлекательных головоломок.

И ничего больше.

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

Остальных лучше тестировать ситуациями, близкими к рабочим. А если такие ситуации сложно сформулировать самому... то не лучше ли поручить проверку кому-нибудь другому?

---

Двое знакомых (и довольно успешных) бизнесменов ищут сотрудников-партнёров так. Дают будущему партнёру поработать над интересными совместными полу- или некоммерческими проектами, и выступают спонсорами этих проектов. Получается не так и дорого, зато всё с человеком становится понятно.

Даже если Вы не бизнесмен, ТК РФ даёт до 3 мес. на испытательный срок. Не лучше ли, вместо того, чтобы изматывать кандидата десятком собеседований, взять его и проверить в реальной работе?

При больших сомнениях, можно взять кандидата внештатником, на месяц, например, по договору подряда, и по результатам посмотреть, что с ним делать дальше.

---

Когда-то на собеседовании мне сначала дали что-то несложное (кажется, про дом и медведя тоже было), что я быстро решил. А потом - вот эту задачку:

Кладоискатели нашли клад и записку в которой было написано: В этих 20 мешках с золотыми монетами есть один мешок с фальшивыми монетами. Известно, что фальшивая монета в два раза тяжелее настоящей.
Задача: Как при помощи одного взвешивания определить в каком мешке находятся фальшивые монеты?

По ходу решения, попросил уточнить про весы, возможность досыпания, количество монет, возможность делить монеты на части. Сказали, что весы электронные, что монеты по ходу взвешивания досыпать нельзя, количество - 1000 в мешке, резать монеты на части - тоже нельзя.

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

А ответ для чашечных весов, с возможностью досыпания монет здесь: http://golovolomka.hobby.ru/otvet/weight9.htm . Но качество приведённого ответа - низкое, т.к. он позволяет проверить монеты только в 1 мешке из 20, и  предполагает досыпание.

---

Как ни странно, именно эта задача, в применении к системным аналитикам, не такая уж бессмысленная.

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

И сможет ли кандидат, посмотрев на "правильный" ответ, сказать, что он неполный, и предполагает изменение условий задачи.

Впрочем, чтобы понять это, интервьюер должен знать, на что смотреть, а не просто оценивать по принципу "решил/не решил". И конечно же, её недостаточно.

---

Кстати, интереснее другое.

Однажды на 23 февраля женская часть коллектива подарила нам "физические" головоломки, типа http://www.puzzle-shop.ru/.

3 человека из 20+ в openspace отложили их в сторону и продолжили работу.

Ещё 2 через пару часов сказали, что все эти головоломки <censored>, и что те, кто их придумал делать и дарить, тоже <censored>.

Остальные, с перерывами на работу, складывали свои и чужие головоломки до конца итерации. А в конце оказалось, что velocity едва достигла 40%. А она, даже учитывая безумную агрессивность планов для борьбы с законами Паркинсона и Голдратта, и менеджмент в строгом соответствии с "теорией X", обычно бывала не ниже 60-70%.

Так что надо бы попробовать дать кандидату на собеседовании пару приятных, но длинных задач (типа пластилина, сложной красивой головоломки или робота Lego Mindstorm), и много скучных, но коротких. И посмотреть на его self time management.

---

Кто осилил - спасибо .