[Тимур]

О задачах цикла аналитика/внедрение

 

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

 

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

 

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

 

 

В первом приближении задача выглядит так

 

- Пообщаться с пользователями и собрать функциональные требования

- Подготовить задание для программистов

- Передать программистам, и согласовать с ними - что из себя должна

представлять система

- принять и оттестировать результат

- показать пользователям

 

На первый взгляд не бог весть что. Так в чем же проблема?

 

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

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

 

1 Нужно уметь очень необычным образом общаться с пользователями -

- уметь слушать с одной стороны внимательно

- с другой стороны критично.

- уметь не только слушать, что говорят люди, но и понимать что они делают

- понимать в чем нуждаются на самом деле

- уметь вытягивать проблемы

- уметь тактично отсекать космические запросы

 

2 Нужно врубаться в проблематику бизнеспроцессов.

- Из рабочего потока (часто хаотичного), нужно вычленять потоки даных.

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

- Уметь видеть процесс в целом, чтобы понимать как данные из начала цепочки отражаются в конце цепочки

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

- Понять какие нужны отчеты и как будут работать контрольные механизмы.

 

3 Нужно ориентироватсья в возможностях технологий

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

- иметь представления о правильной архитектуре

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

 

 

4. Нужно уметь формулировать задачу для программистов в понятных им терминах.

 

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

 

6. По готовности модуля, нужно обеспечить внимательное и всестороннее тестирование

 

7. При пуске очень желательно, посидеть с пользователями и проконтролировать

- что системой начали пользоваться

- что использование правильное.

- что люди осознают функции

 

8 И понять где при разработке прокололись и что нужно все таки переделать. А что стоит доработать.

 

 

Вопросы.

 

 

Вопрос. Как же вы жили раньше?

Ответ. Я же говорил - частично эти задачи решал я, частично ответственные сотрудники в отделах.

Это привело к определенному набору проблем. Из которых бы хотелось бы выпутаться. Если интересно какие проблемы

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

- взаимодействие с программистами не достаточное - в результате они довольно много простояли в тупиках

- пуски очень некачественные

- я не могу больше этим заниматься в третью смену, кроме того у меня получается плохо.

 

Вопрос. Ты же понимаешь, Тимур, что такого специалиста сложно найти даже за космические деньги. А за разумные вообще невозможно.

Ответ. Ага.

 

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

Ответ. Не знаю. Вдруг кто-нибудь что-нибудь полезное скажет.

[nuclearcat]

Пообщаться с пользователями помоему момент с нюансами. Я видел провайдеров, которые шли на поводу 5% активных пользователей. Только их потребности, далеко не потребности основной массы. Причем вытягивать из основной массы, чего они хотят - бесполезно, они этого сами не знают.

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

 

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

 

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

[kapa]

Пообщаться с пользователями помоему момент с нюансами. Я видел провайдеров, которые шли на поводу 5% активных пользователей. Только их потребности, далеко не потребности основной массы. Причем вытягивать из основной массы, чего они хотят - бесполезно, они этого сами не знают.

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

Если я всё правильно понял, то тут не о провайдинге речь шла, а о параллельных разработках. Типа этой: http://topo.rinet.ru/

 

 

Вопрос к Тимуру - а что-то из гибких методологий разработки используете?

И, как вариант, - может, пожертвовать одним из разработчиков с максимально подходящим мышлением и характером, чем искать человека со стороны на такое место?

[telematic]

Тимур, ответ только один - искать человека.

Думаю, для тебя в Москве это проблема времени, усилий и немного денег.

Вот в моей деревне с населением 200 тысяч и отсутствием в радиусе 1000 км. профильных вузов - это реальная проблема.

[Gull]

Занимался я подобным на предыдущей работе года три. Очень напряженная работа, хотя и интересная. Иногда не хватает того драйва, но хорошим разработчикам и платят больше, и с выбором работы лучше.

 

В вашем случае можно попробовать программиста с подходящим характером учить в эту сторону.

 

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

По вашему списку примерно так: двое работающие в связке, пп.1-4 один человек, пп.5-8 другой.

[Тимур]

Все таки хорошо бывает не крутить проблему в своей голове, а изложить ее...

 

Я тут еще подумал над своей проблемой и вот что понял. То есть я попытаюсь уточнить вопрос.

 

Моя проблема не берется появлением в команде человека с большим уровнем соответствующего опыта и профессионализма. И вот почему.

 

Для начала нужно сказать, у нас такие люди в команде в общем-то есть. Но есть одно большое но. У нормального профессионала наша ситуация вызовет только оторопь, потому что уже очень много чего сделано и сделано не правильно. То есть нормальный врач должен поставить диагноз - "ребеночек урод, его нужно сжечь и родить нового".

 

Это во-первых.

 

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

 

Иными словами, нормальный профи меня совершенно не спасет.

 

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

 

Вопросы тогда стоят так. Какие качества критичны для внедренца, как выявить человека с такими качествами и как их развивать.

 

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

[Index]

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

[Дятел]

Второй попавший на неправильное слово....

 

У Тимура пользователи - это сотрудники, использующие соответствующий софт. Какие бонусы? )))

[Ivan_83]

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

[Negator]

На самом деле на мой взгляд Тимуру нужно как минимум 3 человека

 

1.Человек с мозгами со свежим взглядом и прочими прелестями профессионала. Который сможет и задачу оценить, и ТЗ программистам поставить, и общий проект вытянуть.

2.Внедренец который будет с юзерами общаться и обратную связь делать.

3.Маркетолог/дизайн/PR и прочее - это чтобы идею донести на блюдечке с каемочкой, да и вообще оформить так как надо.

 

Причем все эти люди у Тимура есть, я уверен. Разве что кроме первого - вот именно его и искать надо.

А пытаться найти то не знаю что -смысла мало.

[Barcha]

Тимур, кстати, а может поискать тебе ответ в области, что какие глобально ты цели преследуешь пытаясь объединить и "допилить" ваши внутренние системы? Оптимизация бизнес процессов, снижение издержек? Тогда и начинать надо с описания этих самых процессов, на данном этапе ИМХО пофигу, что используется сейчас. После описания что есть, когда будет ясно понятно что и как хочется чтобы было, надо брать команду разработчиков старой системы, замораживать развитие существующего и писать с нуля. Я думаю это единственный правильный метод.

 

P.S. У нас была похожая ситуация, но в меньших масштабах, системы было скажем 2-3, в принципе тоже думали их допилить под новые нужды, но потом поняли, что лучше создать новую с учетом опыта использования нескольких старых. Новую систему написали в стахановские сроки, гораздо быстрее, чем пытались бы срастить имеющееся.

Изменено 25 июня, 2012 пользователем Barcha

[vIv]

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

Нифига юзеры не знают. Это просто аксиоматика юзабилити. За юзером надо ласково следить и замечать, что он делает "не так". Ибо живые люди обладают безграничной приспособляемостью и могут годами делать неудобную херню даже не задумываясь, что она мешает им жить и работать.

 

Буквально сегодня видел ужасную картину: несколько поколений скотча на коврике для мышки, с ближнего края поверх поверхности коврика. Меня аж передёрнуло: это ж адски мерзко и неудобно, вздувающиеся складки скотча режут нежную часть ладони около запястья, а движущаяся рука его постоянно отдирает. Но нет, - тётка уже который раз, судя по ошмёткам, наклеивает новый слой. И пока у неё получается это делать, - она не подумает о том, насколько это неправильно и неудобно, - и уж тем более не будет жаловаться. А решений-то копеечных масса: от тонкого двустороннего скотча под коврик до коврика с силиконовой подложкой. Но для того, чтобы начать об этом ДУМАТЬ, - надо это ЗАМЕТИТЬ. Заметить подобные штуки можно только имея в одной голове обе-две картинки: "как ЭТО делать удобно и быстро" И "как ЭТО делают на самом деле".

 

1.Человек с мозгами со свежим взглядом и прочими прелестями профессионала. Который сможет и задачу оценить, и ТЗ программистам поставить, и общий проект вытянуть.

2.Внедренец который будет с юзерами общаться и обратную связь делать.

3.Маркетолог/дизайн/PR и прочее - это чтобы идею донести на блюдечке с каемочкой, да и вообще оформить так как надо.

ИМХО 1+2 обязаны быть если не одним человеком, то как минимум симбиотами в работе.

[vIv]

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

На прошлой работе я работал в целом отделе таких неопытных и неумных, у нас основная заявляемая и фактическая цель была - делать юзерам удобно ;-)

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

 

Вспоминается история из ТРИЗа:

Некий химик открыл некую реакцию и решил её опубликовать. Позвал комиссию, делает реакцию, - реакция не идёт. Ну, бывает, хотя и странно, - опытный химик, уважаемый. Извинился.

Повторяет, повторяет, повторяет, - всё повторяется. Зовёт комиссию. Повторяет, - реакция не идёт. Эээ...

В итоге выясняется, что он любил работать ночью в одиночестве и насвистывать под нос. И этот свист оказался катализатором реакции. А при комиссии - свистеть стеснялся ;-)

 

Так-что учитывать надо буквально всё: от личных отношений и звонков по телефону до привычной кружки на столе, которую часто прячут при посторонних в офисе. Я вот обожаю по телефону разговаривать с гарнитурой. Придут проверяющие, - гарнитуру стоило бы убрать в стол, а то тело с наушниками в офисе смотрится несколько неорганично... Придётся брать в руку телефонную трубку, да? Ага, ой, - минус одна рука, скорее всего левая, => моя многокнопочная клавиатура с макросами выпала из работы. Аудит софта у доверенных сотрудников вдруг вышибет из работы PuntoSwitcher (нет в списке официально установленного) => очепятки там, где их раньше не было. Ну и так далее. Основная сложность в подобных задачах - убедить юзера, что начальство не пытается за ним следить, чтобы сделать что-то вредное и неприятное, и вести себя надо естественно, так, как ведёшь себя всегда. ;-(

[Negator]

ИМХО 1+2 обязаны быть если не одним человеком, то как минимум симбиотами в работе.

Вот ни разу не соглашусь.

Мое имхо что как раз и нет.

Обычно профессионалы уже переросли стадию прямого общения с конечными абонентами.

 

Второе - нужно обязательно иметь возможность взгляда со стороны - даже профессионалу.

А уж симбионтами -это только к лучшему.

Хотя черт его знает что конкретно делать надо Тимуру.

Изменено 26 июня, 2012 пользователем Negator

[vIv]

ИМХО 1+2 обязаны быть если не одним человеком, то как минимум симбиотами в работе.

Вот ни разу не соглашусь.

Мое имхо что как раз и нет.

Обычно профессионалы уже переросли стадию прямого общения с конечными абонентами.

Профессионалы чего именно? Кручения хвостов кошкам или юзабилити и меж-людского бизнес-общения?

[Ivan_83]

Нифига юзеры не знают. Это просто аксиоматика юзабилити. За юзером надо ласково следить и замечать, что он делает "не так".

Немного по другому: инженера - пользователи.

После того как я начал дома юзать иптв с работы - подправил косяки.

[Тимур]

Сорри, что долго не отвечал. В умате.

 

Вопрос к Тимуру - а что-то из гибких методологий разработки используете?

 

Что такое "гибкие методологии разработки"?

 

И, как вариант, - может, пожертвовать одним из разработчиков с максимально подходящим мышлением и характером, чем искать человека со стороны на такое место?

 

Может и можно, но

а) хороший программист нужнее

б) все таки это не для программистов работа. Тут нужно очень много с людьми возиться.

 

Тимур, ответ только один - искать человека.

Думаю, для тебя в Москве это проблема времени, усилий и немного денег.

Вот в моей деревне с населением 200 тысяч и отсутствием в радиусе 1000 км. профильных вузов - это реальная проблема.

 

Я хочу понять - как искать. Какие качества критичны?

 

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

 

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

 

1.Человек с мозгами со свежим взглядом и прочими прелестями профессионала. Который сможет и задачу оценить, и ТЗ программистам поставить, и общий проект вытянуть.

2.Внедренец который будет с юзерами общаться и обратную связь делать.

 

Игра идет на проценты эффективности. Ее вести сложно если человек с мозгами плотно не общается с пользователями. Скорее вопрос в том, как в человеке, которому не скучно общаться с пользователями вырастить аналитические навыки.

 

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

Нифига юзеры не знают. Это просто аксиоматика юзабилити. За юзером надо ласково следить и замечать, что он делает "не так". Ибо живые люди обладают безграничной приспособляемостью и могут годами делать неудобную херню даже не задумываясь, что она мешает им жить и работать.

 

О!

[Прохожий]

Тимур, хочешь системную подсказку?

 

Перетряхни буквально все, что только можно с двумя вопросами:

1. Надо ли нам именно это делать вообще?

2. Почему мы делаем это именно так?

 

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

 

Парадокс: для увеличения эффективности не надо делать БОЛЬШЕ. Надо делать МЕНЬШЕ, т.е. систематически НЕ делать то, что можно не делать :)

[jab]

Парадокс: для увеличения эффективности не надо делать БОЛЬШЕ. Надо делать МЕНЬШЕ, т.е. систематически НЕ делать то, что можно не делать :)

 

Ну что ж ты так грубо-то. Ты же ему практически в душу плюнул. :-)

[wanderer_from]

Что такое "гибкие методологии разработки"?

Хороший совет (как бы к советам ни относиться).

Гибкие разработки - это agile.

В корне отличается от привычной системы разработки "водопадом", тем, что не подразумевает вообще никакого ТЗ. И может это именно то, что нужно. Основные принципы:

0. Разрабатывается НЕ проект, и НЕ программное обеспечение. Решается проблема.

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

2. Не пытаются решать глобальные проблемы, но последовательное приближение. В отличие от попытки разработать "техническое задание". Т.е. команда определилась, что нужно решить X, который состоит из Y, Z и N. И принимают решение, что нужно решить приоритетно. И решают.

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

 

Почему эта метода может быть выходом из положения?

Потому что метода рассчитана на разработку при сильно ограниченных ресурсах, включая "время, люди, деньги". Начать просто - с малого. Определите какую-то "простую" задачу, которую нужно решить в первую очередь. Потом втянитесь :) Не смотря на кучу умных слов - это просто и понятно - главное, чтобы участники забега понимали, что они делают. А когда задача простая, то и объяснить "что делать" тоже проще.

 

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

[Прохожий]

 

Хороший совет (как бы к советам ни относиться).

Гибкие разработки - это agile.

А есть еще fastfail имени Гугля! ;)

 

 

Ну что ж ты так грубо-то. Ты же ему практически в душу плюнул. :-)

Мудрец, бранящий тебя лучше, чем дурак, хвалящий тебя!

По моему, Соломон ляпнул :)

[jab]

Мудрец, бранящий тебя лучше, чем дурак, хвалящий тебя!

По моему, Соломон ляпнул :)

 

Тут Нагибин в соседней ветке Тимура хвалил... Теперь понятно кто из вас кто. ;-)

[kapa]

Что такое "гибкие методологии разработки"?

В таком случае советую попробовать.

 

SCRUM, "планинг покер", backlog и прочие умные вещи, о которых никогда не вредно знать.

Ещё Kanban стоит упомянуть. После нескольких десятков Scrum спринтов появилось ощущение, что самое время переходить к Kanban-у. Изначально было страшновато.

 

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

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

[jab]

А какой у Вас процент работающих удаленно ?

[Прохожий]

А какой у Вас процент работающих удаленно ?

Более интересный вопрос!