0. MariaTemchina 718 14.03.19 15:50 Сейчас в теме

Стыд и Скрам, часть вторая

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

Перейти к публикации

Сталкивались ли вы с проявлениями Scream Guide в своей практике?


Как про нас написано... Так и живем. (30%, 6 голосов)
30%
Часть проблем знакома (40%, 8 голосов)
40%
Изредка сталкиваемся (5%, 1 голосов)
5%
Нет, ничего подобного не бывает (10%, 2 голосов)
10%
Не пробуем применять гибкие методы, поэтому вопрос не актуален (15%, 3 голосов)
15%

Комментарии
Избранное Подписка Сортировка: Древо
1. user1048024 14.03.19 21:44 Сейчас в теме
Немножко из другой темы, но в принципе о том же

https://infostart.ru/public/1020673/

https://infostart.ru/redirect.php?url=aHR0cDovL29kZXNza2l5LmNvbS96aHZhbmV0c2tpeS10b20tMy9wYXJv­dm96LWRsamEtbWFzaGluaXN0YS5odG1s

"Если серьезно..."

"Руководитель не обладает всеми компетенциями по работам проекта (программистам виднее, сколько займет время программирование)" - паровоз для машиниста? Кто принимает "проектное" решение? Кто обладает большей компетенцией, "опытом"? В данном случае "Руководитель" это не руководитель "Команды разработчиков"?
"Уровень владения информации по проекту повышается у членов команды"
- команда это все кто участвует - это же не только "программисты"?
"Разные взгляды позволяют получить более объективную картину"
- чем больше информации, тем объективней "картина" - чем больше "следов", тем легче найти "криминалисту " "преступника"
"Конечный Исполнитель должен взять на себя ответственность за результат и затраты - это достигается совместным планированием"
- тут смешиваются ЛПР и "советник" - обмениваться " впечатлениями" могут все - принимает решение"за результат и затраты" конкретный "Исполнитель" - ЛПР - пришлите мне пару лимонов :) в личку укажу куда :) возьмёте на себя такую ответственность за результат и затраты?
Чтобы иллюзий стало меньше - есть "технология" "Стыд и Скрам" и есть реальное их "применение" - Принцип неопределённости Гейзенбе́рга, но в экономике
5. MariaTemchina 718 15.03.19 09:51 Сейчас в теме
(1)
Про ссылку на Жванецкого - спасибо, познавательно.
Кто принимает "проектное" решение? Кто обладает большей компетенцией, "опытом"? В данном случае "Руководитель" это не руководитель "Команды разработчиков"?

Еще раз: совместно принятое решение - это более действенно, чем лично принятое соло руководителем.
Но вообще, по Agile не рекомендуется делать проекты, предполагающие кардинальные изменения архитектуры.
6. sergathome 15.03.19 10:05 Сейчас в теме
(5) С чего бы это размазывание ответственности вдруг стало эффективнее персональной ? Это прям какое-то новое слово в управлении...
Irwin; w.r.; +2 Ответить
7. MariaTemchina 718 15.03.19 10:07 Сейчас в теме
(6)
С чего бы это размазывание ответственности вдруг стало эффективнее персональной ? Это прям какое-то новое слово в управлении...


Это очень хороший вопрос! Коллеги, поделитесь - кому удается добиться того, что команда ощущает коллективную ответственность, и за счет чего это получается?
Слава; Winstoncuk; +2 Ответить
8. sergathome 15.03.19 10:16 Сейчас в теме
(7) Команда может ощущать всё, что угодно. Но это всё что угодно никогда не будет эффективнее персональной ответственности каждого. Но для этого нужен качественный менеджмент... И тут мы приходим, (о, какой сюрпрайз!) к выводу, что за всеми тн "гибкими технологиями" скрывается попытка оправдать отсутствие качественного менеджмента ! :))

ps или попытку работать в условиях отсутствия такового, ага
Ta_Da; sevushka; CheBurator; Winstoncuk; oldcopy; w.r.; +6 Ответить
12. w.r. 212 15.03.19 13:56 Сейчас в теме
(8)
тн "гибкими технологиями" скрывается попытка оправдать отсутствие качественного менеджмента

Собственно scrum это про "программист большой, ему виднее". Типа программисты настолько умные, что сами могут царствовать и управлять, только в реальности это ни разу не так. Программисты довольно часто ловят звезду и им кажется, что море по колено. Я думаю scrum - это оттуда
Ta_Da; Winstoncuk; sergathome; +3 Ответить
13. sergathome 15.03.19 13:59 Сейчас в теме
(12) король реально голый. как на любом трупаке наплодилось мух коучей и прочих жЫвотных... ;))
eskor; w.r.; +2 Ответить
9. acanta 55 15.03.19 11:18 Сейчас в теме
(7) Команда ощущает коллективную ответственность если партком поддерживает решения исполкома.
DDA4746; sergathome; +2 Ответить
10. dmitrydemenew 106 15.03.19 11:22 Сейчас в теме
(7)Я считаю, что если Руководитель не обладает необходимыми компетенциями по работам проекта и не готов брать на себя полную ответственность за его реализацию, то проект, с большой вероятностью, обречен на провал. Потому, что проект с коллективной ответственностью - как автомобиль в котором у каждого окна водитель с собственным рулем. Должен быть только один координатор проектных работ, отвечающий за конечный результат и управляющий всеми участниками проектной группы. Мне пришлось участвовать в нескольких проектах с разделенной ответственностью и коллективным принятием решений - к сожалению, не могу назвать это удачным опытом.
Ta_Da; user675041_start2011ruslan; eskor; unichkin; Winstoncuk; oldcopy; +6 Ответить
14. oldcopy 120 15.03.19 13:59 Сейчас в теме
(10)
Я считаю, что если Руководитель не обладает необходимыми компетенциями по работам проекта и не готов брать на себя полную ответственность за его реализацию, то проект, с большой вероятностью, обречен на провал. Потому, что проект с коллективной ответственностью - как автомобиль в котором у каждого окна водитель с собственным рулем.


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


(7)
Коллеги, поделитесь - кому удается добиться того, что команда ощущает коллективную ответственность, и за счет чего это получается?


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

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

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

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

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

После такого назначения проект был завершен в две недели. Первую неделю главврач, который взял на себя руководство, еще пытался играть с коллегами в демократию, а потом просто стукнул кулаком по столу и сказал, что как он решит - так и будет. Быстро согласовали доработки, выполнили, сдали и остались довольны друг другом.
Ta_Da; pfilyk; eskor; dachnik; user623969_dusa; sergathome; +6 Ответить
17. MariaTemchina 718 15.03.19 15:01 Сейчас в теме
(14)
Проблема последних 10% наоборот требует принятия кардинальных решений и возможно даже некоторого конфликта с заказчиком. Так как сложность этих 10% кроется буквально в мелочах. Когда заказчик говорит: все хорошо, но вот тут надо немножечко поправить, а вот сюда кое-что добавить и т.д. и т.п. Поэтому было принято решение и заказчику было доведено, что мы не будем продолжать работу над проектом до тех пор, пока с их стороны не будет назначен ответственный специалист с которым и только с которым мы будем обсуждать изменения, а со своими коллегами пусть он сам находит общий язык.


Знакомая история! Вы сейчас описали роль, которую в Agile принято называть "Владелец продукта". Он отвечает за содержание работ, что делаем, что не делаем. И да - вы правильно заметили, что важно чтобы он был единой точкой входа, определяющей все работы.
Но это про состав работ, а не про выполнение!...
29. Слава 15.03.19 19:20 Сейчас в теме
(7)
команда ощущает коллективную ответственность, и за счет чего это получается?

Когда участники команды вовлечены в процесс принятия решения - появляется коллективная ответственность.
Эта ответственность не заменяет персональную целиком и это не противоположность, а дополнение.
30. oldcopy 120 15.03.19 19:53 Сейчас в теме
(29)
Когда участники команды вовлечены в процесс принятия решения - появляется коллективная ответственность.


Здесь возникает вопрос, а кем в итоге принимается решение? Командой? Если решение принимают все - то это значит что его не принимает никто. И появляется не "коллективная ответственность", а коллективная безответственность.

Всегда нужен руководитель, который может принять решение и нести за него персональную ответственность. Это не значит, что он не должен и не будет прислушиваться к мнению команды, но именно он должен выслушав все варианты и точки зрения принять решение, которое впоследствии станет обязательным для всех участников команды.
43. DDA4746 18.03.19 13:53 Сейчас в теме
(30) Когда-то давным-давно наблюдал, как это работает.

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

На мой взгляд, это лучший вариант "вовлечения в процесс команды", который сочетается с единоличным принятием решения и ответственностью за него (ответственные назначались тут же, контроль - на директоре).
39. Rico17 29 17.03.19 06:51 Сейчас в теме
(7) За счет разделения "предмета ответственности" по компетенциям участников команды в прямой зависимости от рабочей ситуации. Это общее положение. А конкретика всегда конкретна ;)
Ну например, если от клиента пришел чувак бить морду за "криво пришитые рукава", то с ним общается обаятельная девица от группы консультантов... ;)
Дальше работа администратора команды - "награждения непричастных и наказания невиновных"
Следующим выступает "невиновный", который в зависимости от сложившейся ситуации получает общую (неформально-командную) оценку своей невиновности и на конкретных условиях исправляет ситуацию.
Главным в такого рода подходах является насколько команда - КОМАНДА. А это прямая ответственность руководителя. Поскольку за результат ВСЕГДА отвечает (от слова ответственность) руководитель (как бы ему под разными предлогами не хотелось этого избежать).
42. sergathome 17.03.19 19:44 Сейчас в теме
(39) ещё раз - вспоминаем, что эджайл предполагает организацию команд (трайбов, ага) по принципу заказчик [- аналитик] - исполнитель, что ПОЛНОСТЬЮ РАЗРУШАЕТ ....
44. vasily.ovodkov 18.03.19 15:49 Сейчас в теме
(7)Коллеги, добрый день. По поводу коллективной ответственности - мне кажется, это явление уже сложившейся команды. Первый шаг - срабатывание команды, второй - выращивание общей цели, и как следствие - коллективная цель и коллективная ответственность.
47. katbob 03.04.19 11:13 Сейчас в теме
"Но вообще, по Agile не рекомендуется делать проекты, предполагающие кардинальные изменения архитектуры."
Эту фразу я долго искала, однозначно поддерживаю! А можно поподробнее, кто не рекомендует и есть ли ссылки на материал?.
2. w.r. 212 15.03.19 08:06 Сейчас в теме
Команда Разработки несет коллективную ответственность за создание Инкремента Продукта.


Если отвественность коллективная, почему тогда зарплату не платить тоже не отдельным людям, а всему коллективу и пусть ее сами между собой делят. Только потом все друг с другом пересрутся и утопия со "срамом" закончится развалом коллектива и убытками компании
Ta_Da; Winstoncuk; +2 Ответить
3. oldcopy 120 15.03.19 09:24 Сейчас в теме
Руководитель не обладает всеми компетенциями по работам проекта (программистам виднее, сколько займет время программирование)


Мне тут вспоминается закон Паркинсона, который гласит: Работа заполняет все отведенное для нее время.
dachnik; w.r.; +2 Ответить
4. MariaTemchina 718 15.03.19 09:48 Сейчас в теме
(3)
Мне тут вспоминается закон Паркинсона, который гласит: Работа заполняет все отведенное для нее время.

Это хитрый нюанс. Когда все (включая руководителей, разработчиков и заказчиков) работают в тесном контакте, то в большей степени видно, когда люди работают и дают реальный результат, а когда дурака валяют и имитируют бурную деятельность...
11. w.r. 212 15.03.19 13:47 Сейчас в теме
(4) Как правило у знающего специалиста выполнение аналогичной задачи занимает в десятки и сотни раз мньше времени, чем у неопытного. И знающий может на визуальный взгляд работать меньше, позволяя себе расслабиться. Для этого мы и получаем опыт
sergathome; +1 Ответить
15. sergathome 15.03.19 14:02 Сейчас в теме
(11) Более того, вот, например, сейчас, я пишу здесь, но это не значит, что я не работаю. "Потом Штирлиц проснётся ... " (с) ыыыы
16. w.r. 212 15.03.19 14:10 Сейчас в теме
(15) Интересно узнать мнение Марии на этот счет. Возможно это всего лишь иммитация
sergathome; +1 Ответить
18. MariaTemchina 718 15.03.19 15:03 Сейчас в теме
(15)
(16)
Возможно это всего лишь имитация

На эту тему полезно почитать книжку Брукса "Мифический человекомесяц". Комментарии на профессиональном форуме, конечно, не относятся непосредственно к выполнению работ. Но конструктивной работы у специалиста обычно получается 4-6 часов из 8-ми часового рабочего дня, никто не может заниматься разработкой непрерывно - технически не получается...
19. sergathome 15.03.19 15:16 Сейчас в теме
(18) А я считаю, что в творческих профессиях невозможно чётко разделить работу и неработу. Поэтому попытки управлять этим - шарлатанство как оно есть. ;) Кстати научный термин "конструктивной" вообще требует отдельного описания ;)

ps Единственный способ работы в таких видах деятельности это персонифицированные договора с как можно более точным описанием желаемого результата, включая сроки его получения. Никаким скрамом тут и не пахнет.
20. MariaTemchina 718 15.03.19 15:50 Сейчас в теме
(19)
Единственный способ работы в таких видах деятельности это

Коллега, я все-таки призываю к меньшей категоричности! С фразой "Действенный способ работы" - более чем согласна, о да!! С фразой "Единственный способ работы" - никак нет.
22. w.r. 212 15.03.19 17:14 Сейчас в теме
(20) можете работать неэффективно, срывая сроки и не получая результат в конце. Тоже ведь работа так то
sergathome; +1 Ответить
23. acanta 55 15.03.19 17:16 Сейчас в теме
(22) а хорошо это или плохо?
sergathome; +1 Ответить
24. w.r. 212 15.03.19 17:19 Сейчас в теме
(23) конечно хорошо, особенно для заказчика
sergathome; +1 Ответить
33. sergathome 16.03.19 15:07 Сейчас в теме
"Комманд Ком мертв, а мы еще нет!" - пели, обнявшись, отец Виндоуз и
командир Нортон. (с)
34. sergathome 16.03.19 16:18 Сейчас в теме
(20) съедобный сорт всегда один - высший
21. w.r. 212 15.03.19 17:12 Сейчас в теме
(19) конструктивным может быть исправление одной строки кода за минуту. Только человек должен знать, где эта строка находится и что она делает. А это уже квалификация и опыт
sergathome; +1 Ответить
35. sergathome 16.03.19 16:22 Сейчас в теме
(21) молодЕж забыла этот анекдот, про телевизор, мастера, и, 10 рублей. Истории, УВЫ, свойственно повторяЦЦО !

ЗЫ и кое-кто, на этом, всегда...
25. oldcopy 120 15.03.19 17:22 Сейчас в теме
(18)
никто не может заниматься разработкой непрерывно - технически не получается...


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

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

Долгая фокусировка на задаче часто мешает посмотреть на нее под другим углом. Как иногда бывает: решаем какую-то проблему пять минут, час, полтора - уперлись в тупик. Пошли выпили кофе, почитали чего нибудь и вдруг приходит понимание, что все это время мы долбились головой в стену, в то время как за углом есть калитка.
sergathome; +1 Ответить
26. acanta 55 15.03.19 17:39 Сейчас в теме
Это если решать задачу. А если искать выход из положения то задача вообще ни при чём.
27. Yashazz 2373 15.03.19 18:27 Сейчас в теме
А, ещё один крик души про эйджил... Болтовня на ровном месте вокруг надувания щёк с умным видом... Иллюзия систематизации работы, ага...
eskor; sergathome; +2 Ответить
36. sergathome 16.03.19 16:41 Сейчас в теме
(27) вокруг ага. ага. а они кажуть - мы хоть пытаемся..
37. acanta 55 16.03.19 16:46 Сейчас в теме
(36) само ничего не систематизируется (с) Карл Линней
sergathome; +1 Ответить
38. sergathome 16.03.19 16:57 Сейчас в теме
(37) хыхы, некто Маркс, Энгельс и, страшно подумать, Муссолини с ним нифига бы не поспорили...
28. Yashazz 2373 15.03.19 18:29 Сейчас в теме
Первую неделю главврач, который взял на себя руководство, еще пытался играть с коллегами в демократию, а потом просто стукнул кулаком по столу и сказал, что как он решит - так и будет. Быстро согласовали доработки, выполнили, сдали и остались довольны друг другом.

Вот она, единственная правда жизни. Есть волевой кулак - будет успешное внедрение. Нет такого - будет жевание соплей, конфликты и проблемы. И никкакие хитропопые технологии планирования работ не оказывают на это ни малейшего влияния. Ни ма-лей-ше-го.
eskor; dachnik; sergathome; +3 Ответить
31. user1048024 15.03.19 21:56 Сейчас в теме
(28) (30)
И скрам ли тут был, или скрим до того, действительно абсолютно неважно, если есть осмысленное компетентным ЛПР решение - "Есть волевой кулак - будет успешное внедрение", ну или "волевой кулак" - только его разрушит, ведь не всем повезёт с главврачом, и отрицательный результат послужит всем наукой? И чем дальше мы погружаемся в тему, тем больше удаляемся от первоначальной постановки вопроса верить ли в новые методики- "Крик души про иллюзию внедрения Agile", или это про компетенцию заявляющих что они её придерживаются? Картинка со скрамом подозрительно напоминает каскад, итерацию, спираль. И в любом подходе "фокус внимания" подразумевает наличие положительного результата, а иначе как, завтра должно быть лучше, чем вчера. Ну и как мне кажется мнения "главврача" мы тут не услышим?
32. oldcopy 120 15.03.19 22:07 Сейчас в теме
(31)
И скрам ли тут был, или скрим до того, действительно абсолютно неважно, если есть осмысленное компетентным ЛПР решение - "Есть волевой кулак - будет успешное внедрение", ну или "волевой кулак" - только его разрушит, ведь не всем повезёт с главврачом, и отрицательный результат послужит всем наукой?


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

"Коллективная ответственность" грозит же превратить проект в вечные 90%, когда постоянно что-то где-то доделывается, переделывается и исправляется. Особенно если в проекте возникнут какие-либо проблемы. Есть старая поговорка, которая как никогда подходит к данному случаю: у победы много отцов, поражение всегда сирота.
40. Rico17 29 17.03.19 07:32 Сейчас в теме
Я понимаю желание автора на скрам- хайпе заработать очков.
Но при всем положительном эффекте не стоит "пудрить коллегам моск" - скрам - это один возможных способов ТЕХНОЛОГИИ работы команды (это "внутренний" процесс отдела разработки).
А хайп идет вокруг управленческих, кадровых, мотивационных и прочих подходов.
Возникает опасная ситуация, когда руководители соответствующих подразделений перекладывают свою ответственность - НЕ компетентность на "новые импортные технологии разработки" :(
С таким же успехом можно это делать в отношении новых "клавиатур и мышек" )))
eskor; dachnik; w.r.; sergathome; oldcopy; +5 Ответить
41. sergathome 17.03.19 19:32 Сейчас в теме
(40) К огромному сожалению всё гораздо хуже. Так называемые "гибкие технологии разработки" ака скрам, эджайл анд соу он, разрушают само понятие "внутренний процесс" ж))
46. Vladimir Litvinenko 1692 18.03.19 17:03 Сейчас в теме
(41) Потому что это не технологии и не методологии, а набор ограничений, правил и, если повезёт, культуры. Любой внутренний процесс тоже включает в себя набор ограничений и правил. Никаких противоречий нет, просто некорректное использование терминологии, что всегда случается когда терминология проходит через масс-культуру и превращается в товар и "волшебную таблетку".

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

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

https://www.youtube.com/watch?v=0Dj7TDXCEm4
MariaTemchina; sergathome; +2 Ответить
45. acanta 55 18.03.19 15:52 Сейчас в теме
Чем отличается коллективная ответственность в школе от коллективной ответственности в институте?
В школе тех, кто слишком хорошо успевает "награждают" занятиями с теми, кто "совсем не учится" в свободное от занятий время (вместо хобби и футбола необходимо "зажечь" алгеброй или тригонометрией).
В институте эта "премия" за хорошие конспекты и посещаемость снижается до СМС во время экзамена двух-пяти "звездочек" на группу.
Но вот мотивация другая. За помощь в школе баллы (или рейтинг в глазах учителя) добавляются, а в институте за то же самое могут и отчислить за компанию.
MariaTemchina; +1 Ответить
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Санкт-Петербург
Полный день

Консультант 1С
Нижний Новгород
зарплата до 100 000 руб.
Полный день


Программист 1С
Бобров
зарплата от 100 000 руб. до 150 000 руб.
Временный (на проект)

Студент (стажер) 1С
Нижний Новгород
зарплата от 25 000 руб.
Полный день