Автор Тема: Анализ и разработка или разработка и сопровождение.  (Прочитано 2066 раз)

Elf

  • Hero Member
  • *****
  • Сообщений: 578
  • Рейтинг читателей: 31
    • Просмотр профиля
Коллеги, добрый день!
вопрос : сейчас у нас есть отдел анализа и отдел сопровождения. Отдел сопровождения занимается еще и  разработкой.  Вот думаю, назрела потребность  разделения отдела сопровождения на сопровожденцев и разработчиков, но я думаю, что надо делить так:
анализ и разработка - департамент развития,
сопровождение и тестирование - департамент сопровождения.

Поделитесь плиз  своим мнением.
Почему назрело:
-ошибок в разработке масса, потому что - на бою все равно можно поправить.
-документации по разработке нет, потому что -  сам все делал, сам и посопровождаю.
-контакта с аналитиками нет , потому что - зачем спрашивать, мне виднее я же ближе к пользователям.....
ну и в этом духе.
« Последнее редактирование: 01 Февраля 2016, 17:18:22 от Elf »


Григорий Печенкин

  • Member of CAR
  • Hero Member
  • *****
  • Сообщений: 1318
  • Рейтинг читателей: 57
    • Просмотр профиля
    • http://www.greesha.ru
Вижу слово "вопрос", но не нашёл ни одного вопросительного знака. :)
Универсального решения нет, конечно. Мне в предложенной схеме, например, непонятно, почему тестирование ушло в сопровождение.

У вас вообще какого рода клиенты (корпоративные? массовые пользователи?) и сколько их?
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)

Elf

  • Hero Member
  • *****
  • Сообщений: 578
  • Рейтинг читателей: 31
    • Просмотр профиля
Гриша, просто прошу поделиться своим мнением.

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

Пользователи -  корпоративные 1тыс.
Заказчик - бизнес компании.
Клиенты - внешнии физики и юрики из всей станы.


Леонид

  • Sr. Member
  • ****
  • Сообщений: 481
  • Рейтинг читателей: 57
    • Просмотр профиля
Почему назрело:
-ошибок в разработке масса...
-документации по разработке нет...
-контакта с аналитиками нет...

Переименовать и переставить столы? "Эх... А вот когда я молодой в борделе работала,..." (с)

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

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

анализ и разработка - департамент развития,
сопровождение и тестирование - департамент сопровождения.

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

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

Гм. Несколько сумбурно получилось.

Григорий Печенкин

  • Member of CAR
  • Hero Member
  • *****
  • Сообщений: 1318
  • Рейтинг читателей: 57
    • Просмотр профиля
    • http://www.greesha.ru
Если отсутствие контакта с аналитиками - осознанная проблема, то её решать поначалу можно административно. Просто сделать обязательным участие аналитика в обработке запроса клиента. Это можно решить на уровне системы обработки запросов (у вас ведь есть такая?)


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

imho чем ближе документация к коду и чем меньше лишних движений должен совершать разработчик для её написания, тем больше шансов получить что-то полезное. Нужно либо разрабатывать какую-то технику встраивания документации в код (я пользовался javadoc / doxygen - сейчас для этого наверняка есть какие-то новые инструменты), либо вводить практику обязательных содержательных комментариев к коммиту при выкладывании кода. И реализовывать публикацию этих комментариев в ту систему, в которой ими будут пользоваться (например, wiki с продуманной структурой и хорошим поиском). В любом случае требуются энтузиасты и контролёры, само не взлетит.


Что же касается вопроса о том, как правильно делить отделы, то по-всякому можно. Слишком много факторов нужно учитывать (в том числе "политических"), чтобы можно было давать какие-то советы извне. Басню про квартет только тоже нужно не забывать. :)

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

В одной, например, был довольно сильный департамент сопровождения. Держался полностью на его руководителе, который сам занимался и отбором кадров, и их обучением, и поддержанием общей атмосферы в коллективе. Вопросы их взаимодействия с разработчиками, тестировщиками и аналитиками анализировались очень тщательно, описывались в виде регламентов, и фиксировались в системе обработки запросов. В результате создавалось впечатление, что только в сопровождении порядок, а у всех остальных бардак.
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)

Elf

  • Hero Member
  • *****
  • Сообщений: 578
  • Рейтинг читателей: 31
    • Просмотр профиля
Леонид, Гриша, спасибо.
Действительно , посмотрела ситуацию со стороны. Куда не отнеси отдел, если отношение начальства остается прежним, то ничего не поменяется. Здесь надо менять процесс разработки. Но его поменять сложнее, т.е. так как нет требований со стороны заинтересованных людей в улучшении и ускорении предоставления продукта.
У нас все зависит от заказчика. Есть заказчик, который требует завтра и с качеством и тогда  более или менее процесс идет в правильном направлении. А есть заказчик- готовый ждать. Тогда процесс затягивается навечно.
Вот я думаю, может так и надо?
Типа" зачем платить больше, если результат всех устраивает?"
Ведь понятно, если процесс улучшать, то надо определенные затраты, усилия и знания.   А лучше не тратиться пока нет никаких противоречий.


Леонид

  • Sr. Member
  • ****
  • Сообщений: 481
  • Рейтинг читателей: 57
    • Просмотр профиля
Типа" зачем платить больше, если результат всех устраивает?"
Ведь понятно, если процесс улучшать, то надо определенные затраты, усилия и знания.   А лучше не тратиться пока нет никаких противоречий.

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

Есть, наверное, исключения. Не может не быть. Но мне не попадались.

Elf

  • Hero Member
  • *****
  • Сообщений: 578
  • Рейтинг читателей: 31
    • Просмотр профиля
Леонид, вы правы. Модернизация ИТ это самое страшное для компании. Менять бизнес структуру, увеличить бюджет на нее - это нормально, но не на ИТ.
Нам (ИТ) что делать в этой ситуации? Мы последнее звено в этой пищевой цепочке.  Наверху договариваются о бюджете проекта. И если заказчик "щедрый", то  с нас требуют по настоящему". Руководство, конечно, что то имеет от бюджета заказчика, а нам то все равно. Для нас задачи делятся на сложные/трудоемкие и несложные. И бывает так, что проект достаточно сложный и ресурсы ИТ не могут выполнить его в надлежащем виде. Запускаемся как есть и начинается...... Короче, я в мыслях что могу сделать на своем рабочем месте для того, что бы "и вашим и нашим за дешево спляшем".

Леонид

  • Sr. Member
  • ****
  • Сообщений: 481
  • Рейтинг читателей: 57
    • Просмотр профиля
Модернизация ИТ это самое страшное для компании.

Не уверен, что самое. На мой взгляд, руководству часто просто непонятно - зачем?

Менять бизнес структуру, увеличить бюджет на нее - это нормально, но не на ИТ.

А тут как раз все понятно. Инициаторов таких изменений обосновывать потребность учат все, кому не лень. )

Нам (ИТ) что делать в этой ситуации?

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

Мы последнее звено в этой пищевой цепочке. 

Что характерно - даже в компаниях, целиком ориентированных на предоставление ИТ-услуг, все ровно так же. В крупных и сытых, по крайней мере.

И если заказчик "щедрый", то  с нас требуют по настоящему".

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

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

Ну, какой бы ни был сложный проект, и на него найдется болт с резьбой. Я чаще сталкиваюсь с другой проблемой: ресурсы и компетенции есть, как делать - более-менее понятно. Но тут приходит яркий представитель более высокого звена пищевой цепочки и заявляет "Три месяца? Не, не пойдет. Я вчера с заказчиком договорился, что черед 2 недели будет готово. Приступайте!". И приступаем. А поскольку за 2 недели можно сделать разве что не очень качественную имитацию результата, то "гордость" за проделанную работу и успешное применение компетенций просто зашкаливает. Ну, зато премию могут дать - как же, за две недели управились! (конкуренты за 3 обещали).

Elf

  • Hero Member
  • *****
  • Сообщений: 578
  • Рейтинг читателей: 31
    • Просмотр профиля
Ну, лично я, как последний трус и лентяй, просто меняю место работы, когда достает заниматься производственной мастурбацией. На новом месте с 95% вероятности все точно так же с небольшими вариациями, но глупая надежда и новые ощущения позволяют вернуть желание работать и местами энтузиазм. На время.
Я много личного времени и личных нервов потратил в попытках улучшить ситуацию на местах, но не преуспел особо. С баблом спорить сложно. Теперь вместо ситуации меняю стены.
Аналогично. Но я еще более ленивее и трусливее - и вовсе ничего не хочу уже менять. Поэтому пытаюсь найти интересное занятие на старом месте :)


Ну, какой бы ни был сложный проект, и на него найдется болт с резьбой. Я чаще сталкиваюсь с другой проблемой: ресурсы и компетенции есть, как делать - более-менее понятно. Но тут приходит яркий представитель более высокого звена пищевой цепочки и заявляет "Три месяца? Не, не пойдет. Я вчера с заказчиком договорился, что черед 2 недели будет готово. Приступайте!". И приступаем. А поскольку за 2 недели можно сделать разве что не очень качественную имитацию результата, то "гордость" за проделанную работу и успешное применение компетенций просто зашкаливает. Ну, зато премию могут дать - как же, за две недели управились! (конкуренты за 3 обещали).
Ну тут без комментариев - есть удовлетворение и дЭньги, "чего еще твоей душечке угодно".