Понятно что во франче довольно большая интенсивность. После общения с сотрудниками и знакомыми которые ушли из 1С в другие языки программирования, я не понимаю когда они работают. Рассказы о работе сводятся к тому как кто-то притащил новый фильм и они всем отделом его смотрели и как обсуждали какие-то гаджеты на форуме. Ну все как на мисте. Я не понимаю как при таком раскладе пишутся программы. Понятное дело фикси и фри. У них большая часть обязанностей связанна с поддержкой, да и задачи на разработку вываливаются периодически. Да и работу фикси сложно перенести на себестоимость произведенной продукции. Ну не участвуют они в производстве. А вот у софтостроителей главное производство как раз проги. При этом они же постоянно рассказывают о срывах сроков.
У кого был опыт работы в подобных конторах? Как там ведется учет выполненной работы? То что я описал выше это норма или мне попадаются не удачные примеры?

срыв сроков - это 99,9% вина менеджеров проекта

(0) Эмпирически.

никак не ведется. это норма.
там же не бывает сдачи отчетности :)

п.с. сам только 5 лет назад наоборот на 1С перешел.

Есть отдел разработки. Ежемесячновыставляем типа КТУ каждому сотруднику

линейкой

(0) тест на знание программирования

(0) Как работают, таково и качество продуктов.

(4) Дуристика.

(8) Ну придложи что-либо. Умник, мля

(4) Еще по прошлым временам, КТУ вещь может и логичная. но в нашей коррупционной стране чревата кумовством. Не объективно это. Любимчики, враги и т.д. и т.п.

(9) я уже предложил.

(9) А вам фонд ЗП поделить? или что надо. причем тут эффективность прога и распределение бабла

(10) +1

(11) Твое предложение ничем не отличается от нашей системы.
(12) Фонд ЗП отдела разработки

(0) У них то самое, что у одноэсников. Один в один. Проекты, руководители, задачи, загрузка, отчетность...

(14) а у вас сдельщина что ли?

(16) не совсем. Есть ФЗП, котрый формируется из нескольких источников.

(1) +1

Тайм шит и план работ: все шелковые.

(1) в 90% несофтовых конторах прог сам себе менеджер проекта

самый большойкосяк - это когда от твоего обновления сеть из 100 магазинов не может продавать... вот тогда седины прибавляется...

вообще - показателем является реализация хотелок в срок

и отсутствие обкакосов как в (21) (ну и в более мягких вариантах)

Меня что заинтересовало. Поговорил с бывшей одногруппницей. Она у нас работала прогом. Сейчас работает в конторе разрабатывающей банковский софт. Единственное преимущество работу в это конторе она называет "меньшую интенсивность работы". При этом проги у нас по клиентам не ездят делают работы по ТЗ в офисе, с чаем печеньками и прочими плюшками. По вечерам никто никого не заставляет работать. Пытаюсь понять что кроется за "меньшей интенсивностью труда". Просто не вижу грани. Если сотрудник на работе ничего не будет делать, то нафига он нужен. А если на работе заставляют работать, то у вас слишком тяжело. Вот я пытаюсь найти грань.

Оценивать работу разработчика практически невозможно...

(24) вот интересно, как ругают прогов в банке, когда из-за их ошибки уведут пару миллиардов...

(21) а обкатать на одном кролике? Вот например мы завтра начинаем обкатывать на одной точке... из 300... новшества...

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

програмная = логическая

(25) >> Если сотрудник на работе ничего не будет делать, то нафига он нужен.
Месяц он может думать,  придумывая алгоритм который пишется потом  за пару дней...такое оценивать не возможно впринципе.

(28) И как это может сделать "сеть из 100 магазинов не может продавать"?

(31) обосраться можно миллионом способов

(30) тебя уже уволили, следующий!

(33) да вот, что-то никак уволить не могут )

(34) ты реально 30 рабочих дней (1,5 месяца) "думаешь"?

и потом 2 дня делаешь?

или хотят уволить, но ты брат гендира?

(35) скажем так..я могу неделю, две думать и только потом, что-то делать...если понадобится думать месяц - значит месяц...
лучше день потерять - потом за 5 минут долететь(c).

(35) а чо...я тут неделю думал... перебрал 10 вариантов... зато потом стёр всё написаное и за час написал красиво и оптимально...

(39) да понятно, что мысль может прийти в разное время, если надо подумать - надо думать, а не ложить "сто магазинов"

Ну если задачу нужно решить за 2 недели, а я размышлял над ней 4 недели+2 дня писал. Это как бы неудовлетворительный результат.

Мы вроде не теоретической физикой занимаемся. У нас задачи гораздо приземленные, чтобы их столько обдумывать. Хотя из опыта, если никто не дергает (и сам не отвлекаешься), то редко когда задача обдумывается больше 1-2 дней.

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

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

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

(41) в софтверных конторах, где есть проектирование, такой херни тебе бы делать просто не пришлось. Программист получает уже продуманную архитектуру, декомпозированную до классов и там всяких взаимодействий, представленную в простом и понятном графическом виде. Медитировать там не надо.
Те, которые эту архитектуру стряпают, тоже получают для начала своей работы строго определенный набор достаточно документированных артефактов и тоже не маются куйнёй и изобретением велокатов.

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

(45) так ты оценишь только качество альфа-тестирования, а не работу разработчика

(47) Это пример одного из способов оценки качества. Еще есть код-ревью в серьезных компаниях.

+(48) Обычно на задачу выделяют сроки и следят чтобы разработчик в них укладывался, а не сидел в одноклассниках.

(46) -> (20) речь не про софтовые конторы

а, мля, про софтовые :))

+(46) а еще я забыл упомянуть, что из кофемашин в таких конторах течет радуга и там много бабочек летает в некоторых местах

(46)"Программист получает уже продуманную архитектуру, декомпозированную до классов и там всяких взаимодействий, представленную в простом и понятном графическом виде." булщит, это не программист а кодобоец

+(53) Такого нет. Нормальные программисты знают паттерны и классы пишут сами, без предоставленных UML-диаграмм. Общую архитектуру приложения там выстраивают архитекторы.

(46) написал бы, где нужно смеяться..
(54) и Вам наше искреннее хаха

(55)что не так?

(54) сколько ты таких нормальных лично живыми видел?

(43) это только донцова и подобные пишут книгу в определенный срок

(57)Сужу исключительно из своего опыта и опыта знакомых. Штук 10 знаю.

(59) это ты 10, зарабатывающих айтатаыщ, одинэсников знаешь или 10 кодеров, которые понимают UML и знают шаблоны проектирования?

(56) не так то, что адресовал сообщение к (53):):) ссорри

(60) Java-разработчики с различным опытом. Основные паттерны "банды 4ех" они знают, про j2ee паттерны не берусь говорить. ЮМЛем некоторых из них можно и удивить ))).

(44) кстати, плюнь в глаз коллеге - нет там понятия "ротация", есть "простой"

(62) ну, то есть, эти 10, они на поверку все разные и далеко не все владеют умээлями и паттернами. Что и требовалось доказать

(64) Я что-то пропустил?! Здесь кто-то кому-то пытается что-то доказать? Среди этих 10 человек 4 сеньора, 3 миддла и остальные джуниоры. Опыт у всех разный, некоторые джуны юмл не знают. Паттерны используют все, без них в джаве никуда.

(47)И то не факт :)
Качество тестирования измерять количеством багов -- не очень правильно