346

Работа / Ошибки при написании вакансий

« : 16 Августа 2011, 14:55:31 »

Молодой энергичный - булшит. Уже настораживает.
c) написание тест-кейсов; - не то, чтобы это было плохо, но зачем выносить в отдельный пункт? Не проще ли перечислить ожидаемые проектные документы в одном пункте?
5. Всегда отстаивать свою точку зрения, не забывая про работу в команде. - Это обязанность?!
6. Организовывать вокруг себя плодотворную среду, развивая себя и коллег. - булшит
7. Готовность и умение решать сложные задачи и добиваться результата. - как только начинают говорить про "сложные" и "интересные" задачи - жди подвоха
8. Блестящая грамотность, аккуратность и удивительная способность излагать мысли — как устно, так и письменно. - без комментариев.
11. Возраст — до 25 лет. - интересно, а знание ТК РФ входит в требования  к квалификации HR? Что там у нас полагается за нарушение законодательства?

1. Небольшая, молодая, но уже известная компания — опытные коллеги, много возможностей, пространство для роста, поощрение амбиций.
2. Дружная команда с чуткими коллегами
3. Интересные проекты, обычно сложные или очень сложные. - рассадник штампов.

4. Уникальная возможность работать сразу на нескольких проектах развивая себя в разные стороны. - в переводе на русский - "у нас постоянный аврал, приготовьте валокардин"
5. Пространство для творчества и реализации идей (в том числе очень креативных). LOL

347

Обсуждение статей / Re: Рецепт работы с требованиями

« : 11 Августа 2011, 14:23:26 »

Для того, чтобы определение "легло" нужно работать в одном ментальном поле. А потому прежде чем чего то определять, предлагаю посмотреть CMMI.

Requirements Development - Process Management
Requirements Management - Project Management
Это в частности означает, что управлением и разработкой занимаются разные люди. Попытка отдать управление требованиями инженеру-аналитику может иметь фатальные для проекта последствия.
Проверено. Имеет. Как минимум, очень неприятные.

Requirements Development - третий уровень
Requirements Management  - второй уровень
Это в частности означает, что управление тербованиями нужно ставить до разработки требований. В противном случае - это выкинутые деньги. Чато это делают наоборот. С известным результатом. Попытка отстроить разработку требований без отстраивания управления требованиями может иметь фатальные для проекта последствия.
Проверено. Имеет. Как минимум, очень неприятные.

348

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

« : 29 Июля 2011, 23:25:13 »

Это все какие-то эскимосы тебе попадались. Это точно в Москве было;)?

Это "Записки автоматизатора" Андрея Орлова

349

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

« : 29 Июля 2011, 19:39:37 »

- обладание способностью грамотно писать и формулировать мысли в виде текстовых предложений

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

Быль 1.  В 1995 году подобрал я компанию, готовую поставить информационную систему для фирмы, в которой я тогда работал. И стали мы обсуждать, как эту систему настроить. И мне впервые назначили менеджером проекта человека, для которого правильнописание было тайной за семью печатями.
Через некоторое время я сообщил их директору, что долго такого не выдержу, и попросил заменить внедренца или хотя бы обучить его пользоваться проверкой орфографии в Word. Следующий документ он мне вручил, торжественно заверив, что теперь, получив взбучку, он проверяет тексты очень внимательно. Документ назывался «МАТЕРЬЯЛЫ К ЭСКИЗНОМУ ПРОЭКТУ». В параметрах Word было указано не проверять слова из прописных букв…


Быль 2.  Очередная организация наняла меня слишком поздно: сторонние внедренцы уже сделали вид, что провели предпроектное обследование. В результате еще месяц ушел на переделку технических заданий на доработки. Одним из требований, на котором я настаивал, было добавление в справочник контрагентов дополнительного поля для аббревиатуры в пять символов. Сокращенное название контрагента в выбранной тиражируемой системе занимало двадцать символов и не влезало в шахматки, которые широко использовались в организации.
Требование для этой системы пустяковое, руководитель проекта от внедренцев на него сразу по телефону согласился, но в очередной версии ТЗ аббревиатуры не оказалось. Звоню, удивляюсь, в ответ слышу: «Ах, простите, щас добавим». Приходит следующая версия ТЗ – нужного пункта нет. После трех итераций еду к разработчикам и понимаю, что единственной проблемой для включения требования в ТЗ было неумение написать слово «аббревиатура» менее чем с двумя ошибками кем-либо из внедренцев. А Word больше одной ошибки не исправляет…

350

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

« : 25 Июля 2011, 12:55:06 »

Деминг писал, что в долее чем 90% случаев брака вина лежит не менеджменте (смотри "Выход из кризиса"). Очень элегантно это демонстрируется експериментом "Красные бусы".

А теперь предложение.
Поделить причины на внешние и внутрение. Давайте попробуем начать классификацию. Оно конечно по правилам мозгового штурма рановато начинать. Сначала нужно накидать побольше. Поэтому рассматривайте это предложение, как спасоб выявления новых причин.

Какие качества аналитика влияют на качество документов Аналитика?

351

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

« : 21 Июля 2011, 11:18:00 »

То есть обычно документацию пишут для того, чтобы искать ошибки? Ну что бы было кому за что официально платить зарплату? Так получается?

Пишем документы для поиска в них ошибок. Странная логика. Galogen, согласна с тобой.

Понял. Зря вырвал фразу из контекста.

...На самом деле суть вотерфола в другом — он основан на посылке, что раннее обнаружение ошибок удешевляет разработку. Для этого документы и пишут — чтобы их проверкой можно было найти ошибки тогда, когда кода еще нет. Во многих ли конторах практикуют формальные инспекции документов? То-то же. Нафига их писать, если их не проверять. Эдак их дешевле вообще не писать — результат тот же. ... (с) http://gaperton.livejournal.com/5759.html

352

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

« : 19 Июля 2011, 18:45:15 »

Давайте порассуждаем - что может влиять на качество выпускаемых документов Аналитиком и что с этом делать?

0. Отсутствие процесса тестирования документации. Если вы не ищите ошибки в документации, то зачем вы вообще документацию пишете? Она просто не нужна.

353

Обсуждение статей / Re: Рецепт работы с требованиями

« : 19 Июля 2011, 14:06:41 »

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

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

Buenos días, amigo!

354

Методологии / Re: помогите отмахаться от ГОСТ 34

« : 04 Июля 2011, 11:09:23 »

ГОСТ 34.602 очень сильно помогает писать
Отличный формат. Позволяет мало думать о структуре и больше о содержании.

355

Конференции Семинары и Тренинги / Re: Отзывы о ЛАФ 2011

« : 27 Июня 2011, 14:18:39 »

4. О чем вы или с вами говорили в кулуарах или на второй день, чтобы понять, что интересует народ и опираться на это для формирования след программы.

* Просили расшифровку моего доклада.
* Мне были интересны методы контроля качества альтернативные тестироанию.
* ТОС в применении к разработке ПО, но это не анализ.
* Разделение по разным ролям управления и разработки требований.

5. Ваши мысли по поводу того, какие конкурсы можно сделать на след ЛАФ, чтобы было всем также весело и интересно.

Мисс ЛАФ. Сообразили поздно. Можно было и там сделать.  Делаем три фото каждой мисс:
* официальная с первого дня
* пляж
* в выходном платье на втором дне

356

Конференции Семинары и Тренинги / Re: Отзывы о ЛАФ 2011

« : 27 Июня 2011, 14:12:14 »

-- 1 -------------------------
Из наблюдений за выездными конференциями, с совместным проживанием:
Второй день всегда, всегда! будет разгрузочным. Исключения из этого правила может и существуют, но нам относятся слабо. После банкета первого дня - хорошая форма - это ленивые беседы на пляже, примерно до 16:00-17:00. Потом может быть что-то серьезное.

Хорошая форма - 3-4 дня. Третитй день хорош, для альтернативных докладам форм - мастер классы, круглые столы, ... Очень хорошо, если на основаниии круглого стола первого дня на третий быдет подготовлена выжимка, новая повестка и попробовать раскрутить тему дальше.

Недостаток формата в 3-4 дня известен. Меньше возможностей приехать. И чуть дороже.

-- 2 ------------
Рассмотрим проблему задержки послеобеденных докладов:
1. Медленное обслуживание в кафе
2. Задержки передобеденных докладов
3. Незнание местности

1. С первым предлагаю ничего не делать. Переход на бизнесланч - это упадничество.
2. Выгонять. Пусть задают вопросы на обеде. Там им и место.
3. Хорошая практика - у онформационного столика повесить схему прилегающих окрестностей с описанием питательных мест формата А1-А0.
4. Дать больше времени на обед. + 10мин.

-- 3 ------------
Повысить качество докладов можно. Для этого нужно работать с докладчиками. Работать.

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

-- 5 ------------
Временной регламент.
Это не Москва. В Иваново лучше начинать в 8:00 - 8:30. Максимум в 9:00 должен начаться первый доклад.

357

Обучение / Re: Книга: Введение в UML от создателей языка

« : 22 Июня 2011, 12:47:19 »

За меньшие деньги можно Коберна купить.

358

Для всех / Re: Какие вопросы вы задаёте заказчику?

« : 17 Июня 2011, 01:07:47 »

С ЛАФ-2010:
- Как вы узнаете, что проект был успешен?

359

Для всех / Re: Какие диаграммы использовать для процедурных яызков впрограммирования.

« : 14 Июня 2011, 11:58:09 »

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

ER, размещения, юзкейсов, активити, EPC, объектов, состояний, размещения, и все остальное. Как влияет язык реализации на типы диаграмм проектирования и анализа?!?? Да никак.

Ваш вопрос звучит примерно так: "ПК какой марки мне использовать для построения проекта дома, если для заливки фундамента я буду использовать песок из калабухинского карьера вместо карамзинского?"

360

Обсуждение статей / Re: Управление качеством ПО в Agile

« : 14 Июня 2011, 11:48:39 »

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