Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - SALar

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 »
106
Работа / Re: Как стать аналитиком?
« : 30 Июня 2015, 12:24:16 »
Могу порекомендовать еще одно направление развития. Как по мне - самое эффективное, но и самое труднодостижимое.
А именно, всеми правдами и неправдами набейтесь в подмастерья к практикующему аналитику выше среднего уровня. Попросите объяснить, научить, проконтролировать в первых (и последующих) шагах, поправить и направить. Собственно, всё.
+1
Уж насколько плохо четвертое правило воронки, но самостоятельное изучение еще хуже.
Будете трактовать закон гравитации как в "Пасынках вселенной" Хайнлайна.

107
Работа / Re: Как стать аналитиком?
« : 26 Июня 2015, 13:25:23 »
"Организация как система" Генри Нив

108
Я полагал, что бизнес-аналитик этот тот, кто проводит анализ аналогичный описанному в книгах Шрагенхайма "Управленческие дилеммы. Теория ограничений в действии", http://www.ozon.ru/context/detail/id/3564526/ , Детмера  "Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию", карт Шурарта и т.д. IT-шником при этом быть совсем необязательно. Главное быть бизнес аналитиком.

И, как правило, проблемы бизнеса никак не решаются внедрением IT-систем. Гораздо эффективней решения в другой области. Например, в случае аутсорсинговых компаний типа Люксофт или Епама достаточно контролировать, чтобы на скамейках запасных было не менее определенного процента людей. Цифра эта известная, достаточно открыть справочник. И да, попытка внедрить какую нибудь очередную "систему управления проектами" будет только вредить.

109
Хочу узнать как после обследования понять что все(нужные) требования собраны?
Когда вы написали и утвердили программу и методику испытаний. Мне нравится по ГОСТ 34.603, но ничего не имею против легковесного "How to demo?"


Т.е как проводить тестирование, проверку требований?
Смотри мои доклады на ЛАФ-2010 и на SQADays-10. Они по 45 мин - для начала пойдут.


Какие документы кроме Отчета об обследовании могут быть написаны не забегая сразу до ТЗ.
Их такое количество, что просто жуть. Я до ТЗ обычно пишу "План обеспечения и контроля качества" пример есть в моем блоге blog.shumoos.com Если удается, пишу "Заинтересованные лица проекта и их интересы". Vision очень неплохо бы прописать. Но с ним засада. По требованиям Тойоты Vision на миллиардный (в долларах) проект должен убираться на А4. А так коротко писать умеют не все. Моя рекомендация по Vision и шаблон - у меня в блоге. Есть еще отличная работа Бескова: http://beskov.ru/2008/05/%D0%BA%D0%BE%D0%BD%D1%86%D0%B5%D0%BF%D1%86%D0%B8%D1%8F-%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0-%D0%BA%D0%B0%D0%BA-%D0%B8%D0%BD%D0%B6%D0%B5%D0%BD%D0%B5%D1%80%D0%BD%D1%8B%D0%B9-%D0%B4%D0%BE%D0%BA/

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


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

110
Какое ПО позволяет делать фасетную классификацию задач?
Плохую - почти любой трекер.
То что меня устраивает - TrackStudio
Хорошую - не, не слышал

111
Для всех / Re: Пишем ТЗ по ГОСТ 34
« : 26 Февраля 2015, 00:14:17 »
И про статью. Там высказаны достаточно любопытные мысли человека, который пытался разобраться в чем-то, в чем он не очень ориентируется. Если коллегам интересно, могу разобрать ее "по косточкам".
Я знаю, что  я в этом не слишком силен. Я просто пытался разобраться. Один черт, материалов очень мало.

Так что, я готов, оппонент. Я действительно хочу понять, где не прав.

Вызов принят. Мы  не хотим самоутвердиться, мы просто делаем рекомендации.
Не будем резки друг к другу, просто я ваш оппонент.

Принято?

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

112
Для всех / Re: Пишем ТЗ по ГОСТ 34
« : 23 Февраля 2015, 20:52:16 »
И еще немного добавлю. 34.602, это не требования к ПО!!!! http://blog.shumoos.com/archives/288

113
Для всех / Re: Пишем ТЗ по ГОСТ 34
« : 23 Февраля 2015, 20:51:25 »
В ТЗ у госов каждое второе требование примерно такое. Когда от недоработки, но чаще потому, что так и задумано.
Обычно так задумано. "ТЗ для аудиторской проверки, а работать будем по нормальным документам."
Хотя по ГОСТ-ам вполне можно  работать. Если есть желание, и главное, знания. Знаний обычно нет. В результате изобретается "стыд&срам"

114
Правда, формат антикафе не очень понравился: ушли голодными. Надо найти такое место, чтобы и поговорить, и поесть. Причём так, чтобы и добираться всем было удобно (а значит, не очень далеко от центра), но и припарковаться чтобы можно было без проблем (а в районе Тверской, где проходила первая встреча, с этим проблемы). Если вы знаете такое место, делитесь рекомендациями в этой теме.
Нам очень понравился http://www.boondockpub.ru/ м. Сухаревская
Припарковаться можно во дворе, куда ходят курить. А мотоциклы паркуют у парадного входа на тротуаре.

115
Угу. И в 10 пункте есть ключевое утверждение, которое почти все, всегда пропускают. И совершенно неизбежно получают плохое управление большим количеством задач.

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

Далее отобранные фичи прорабатываются продюсерами/бизнес-аналитиками, готовится детальный дизайн-документ, составляется список фич в виде:

Feature - Sub-Feature - Sub-Feature Element.

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


По результатам оценки уточняется таймлайн проекта, даты майлстоунов. Делается распределение фич и подфич по спринтам. Уточняется количество ресурсов, которые необходимо привлечь на проект для выпуска продукта в срок.

Выполняется нагрузочное планирование (capacity planning). Создаётся детальный план, который учитывает объём работы, имеющиеся ресурсы и длительность проекта. Имеющиеся технические задачи распределяются между сотрудниками. План обновляется для каждого майлстоуна, т.к. входе работы над проектом ситуация может меняться. Учитывается overhang для всей команды. Если сильно не успеваем, то некоторые фичи могут быть отменены.
Очень нравится подход. Это сильно лучше того, что часто встречается. Т.е. на мой взгляд это дает очень серьезные преимущества. Если еще и проверка полноты атомарных задач поставлена на уровне, то ... мои аплодисменты. Это круто.

PS. Я бы не стал делать нижнюю грань трудоемкости для атомарной задачи. Но это обсуждаемо. Может я и не прав.
Верхняя очень близка к тому что я стараюсь использовать. Я бы сказал полнедели и добавил бы еще два условия: атомарная задача это не более одного исполнителя и не более одной информационной системы. Опять же обсуждаемо.

PSS. Это скорее техническое замечание. Мелкое.
> Feature - Sub-Feature - Sub-Feature Element.
Это один из видов классификации. Я бы предпочел фасетную классификацию. Понимаю, что сильно сложнее, поэтому не готов рекомендовать для всех. Скорее всего, ваш способ лучше для вас и для многих других.
-----------------------
Может рекомендации Кирилла в FAQ вынести? Достаточно стройно. Что скажете комрады?

117
Работа / Re: Изменения на рынке труда
« : 27 Января 2015, 16:15:01 »
Виктор, заходим на HH, смотрим вакансии по словам «системный аналитик» — 192 вакансии за месяц.
Уточняем «Опыт от 6 лет» — остаётся 4 вакансии.
Совершенно верно. Причем 6+ это всего лишь средний уровень. Не высокий.
Как правило. Исключения вполне возможны.

118
Давайте я вам порекомендую одну из своих статей по нескольким методам управления задачами в зависимости от типа производственно потока V.A.T.I. Статья не сильно простая, что делать. Управление штука сложная.
Форд, Тойота и морские свинки

119
Попробую ответить в одном посте.
1.
"Peapleware" Том ДеМарко, Тимоти Листер - http://www.ozon.ru/context/detail/id/2338486/ Книги под ракой нет, но ЕМНИП это примерно 70-80 стр, слева.

2.
Цитировать
А можешь приблизительно указать место в книге где находится это обоснование?
Какая глава хотя бы, хочется внимательно перечитать
Размазано на несколько глав. Из-за особенностей нашего мышления, лучше перечитать полностью. Конкретное место можно найти по словосочетанию "студенческий синдром". ЕМНИП.

PS. если хотите разобраться с проблемами  мышления и почему нужно перечитать полностью, рекомендую:
http://lesswrong.ru/w/%D0%97%D0%B0%D0%BF%D0%B0%D1%81%D1%91%D0%BD%D0%BD%D1%8B%D0%B5_%D0%BC%D1%8B%D1%81%D0%BB%D0%B8
и
http://lesswrong.ru/w/%D0%9A%D0%B0%D0%BA_%D0%BA%D0%B0%D0%B7%D0%B0%D1%82%D1%8C%D1%81%D1%8F_%D0%B8_%D0%B1%D1%8B%D1%82%D1%8C_%D0%B3%D0%BB%D1%83%D0%B1%D0%BE%D0%BA%D0%BE%D0%BC%D1%8B%D1%81%D0%BB%D0%B5%D0%BD%D0%BD%D1%8B%D0%BC

3.
Цитировать
Ну почему же?
Согласно теории ограничений всегда есть более слабое звено, этого не избежать.
Ну это же не значит что надо работать в полсилы? Тогда получится что более сильные звенья еще меньше нагружены.
Нет. Здесь есть несколько моментов. И почти все они противоречат нашим "запасенным мыслям".
* ограничение системы должно быть нагруженным. Остальные рабочие центры обязаны работать "неэффективно". Попытки заставить неограничения системы работать максимально эффективно следует пресекать. Именно поэтому я резко против KPI.
* Если ограничение системы находится вне фирмы, то все отделы обязаны работать "неэффективно".

Цитировать
Просто надо выполняя работу, параллельно искать и укреплять самое слабое звено.
Э-э-э... Все сильно сложнее. Различают минимум три варианта: "уникальность"; "Наибольшая трудоемкость"; "наилучшая управляемость".

4.
Цитировать
а если проблема не возникла и не появилось этих "бутылочных горлышек", то вполне применимо.
Это невозможно. В принципе невозможно. В караване всегда есть самый медленный корабль.

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


-------------------------
Если есть желание, можно устроить обсуждение вживую или по скайпу. Так мне будет проще ответить на все вопросы.
Я тут прикинул во время прогулок (это около 10 часов размышлений). что чтобы ответить на изначальный вопрос обсуждения, мне нужно написать порядка 30 000 слов. Это явно не пост в форуме. Ах, да, а потом это должно пройти проверку и знатоков ТОС, психологии, теории вариаций и т.д.

120

Ну вообщем-то каждая задача должна быть оценена (непосредственным исполнителем, заказчиком, тим лидом) как минимум по таким параметрам как: ... и трудоемкость (оценивается обычно разработчиками),
Что согласно статистическим исследованиям, приведет к снижению производительности в 1.5 - 2 раза. Смотри книгу "Peapleware". У Голдратта в "Критической цепи" приведено теоретическое обоснование для этих наблюдений.


Эта система позволяет постоянно держать нагрузку на все звенья разработки.
Что согласно "теории ограничений" совсем не хорошо.



Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 »