Мне кажется сейчас проще найти примеры ТЗ в сети и корректировать их, чем искать техписа знакомого с ГОСТами и их типичными формулировками, ну либо писать самому, ничего смертельно сложного в этом нету. Ведь техпису тоже надо объяснить о чем надо писать собственно, а так вы сами знаете и лучше можете сформулировать по примерам. Главное правило составления — устранение разночтений одних и тех же предложений.
А вам это так надо? Собственно стандарт нужен в лучшем случае при работе с гос-проектом, а в остальных случаях есть более специализированные и современные варианты. Я раньше тоже по ГОСТУ писал, для гос-проектов как раз, но из частных заказчиков это мало кому надо.
Не совсем согласен с последней фразой. Если руководитель сам бывший программист, то управлять программистами ему будет проще, потому что он понимает что они делают, им сложнее будет навешать ему лапши на уши. Так любые дополнительные навыки и знания всегда хорошо.
Вообще-то конкретно игры тут не причем, вся соль в том что у программиста к моменту назначения на должность тимлида или менеджера проекта (не дай боже) не сформированы управленческие скилы и способ мышления, грубо говоря нет опыта и знаний — тогда он плохой руководитель. Но если человек самообразовывался, подмечал работу своего начальника и другими путями копил опыт, то при назначении он вполне может быть неплохим начинающим руководителем. И не надо валить все на игры )
Ну я не пробовал, конечно, но думаю и в офисной работе это можно решить чисто организационными и техническими методами. Устранив допустим взаимодействие между тестерами и программистами, снизив до минимума взаимодействие между сотрудниками вообще как это бывает при удаленной работе. Каждый должен быть сам за себя, коллективизм тут во вред.
Хотя может для классической офисной работы такой вариант и не покатит, было бы интересно услышать мнения опытных офисных менеджеров и руководителей на этот счет, а ещё лучше произвести эксперимент )
Ну я это тоже понимаю ) Но я просто к тому что закладываются некие стандартные нормы, без вычисления на основе MTBF допустим, потому что это тоже не абсолютный показатель, а соответственно и толку с него немного.
А у вас данные хранятся на единственном диске?? Вообщем-то какие-то важные данные хранятся в рейд массивах с зеркалированием и вероятность их потери достаточно низкая. А конкретно цифры о которых идет речь в реальной работе по вашему как-то используются или хоть кто-то обращает внимание на них? Может какие-то вычисления проводятся? Я лично сильно сомневаюсь, просто заранее закладывается возможность того что винт полетит, поэтому важные данные дублируются — всегда.
В практических целях в большинстве случаев разумнее использовать модифицированные алгоритмы поиска в глубину. Кто-то делает поиск с возвратом, кто-то поиск от разных вершин. Я предпочитаю первичное разбиение графа на сегменты, так чтобы каждый сегмент удовлетворял правилу Дирака разумеется и после нескольких циклов дробления и составления участков пути поиском в глубину снова объединяю. Я таким образом в университете решал эту задачу, можно было бы найти код, но возможно не я один так делал, с терминологией у меня к сожалению несколько печально, так что может я также не знаю название этого алгоритма )
Да, до боли знакомые процессы. Вообще agile методологии хорошо подходят в плане гибкости сроков, оплаты и взаимоотношения с клиентом. Потому что наперед выдается продукт и заказчик быстрее видит результат, проще вносить какие-то изменения. Раньше я больше к RUP склонялся, импонировала изначальная четкость задач, но со временем такой подход стал костью в горле )
Есть ещё маленький фокус, за который вас правда будут ненавидеть, но сроки ускорите если уж совсем жмет: конкурентная разработка — каждая задача решается двумя допустим людьми, или двумя командами если очень большая, после сдачи обе команды тестируют до чертиков работу противника ) По совокупности затраченного времени и количества выявленных багов начисляются баллы. В конце проекта по этим баллам назначаются хороооошие премии ) Ну и к тому же рейтинг программистов позволяет давать лучшим более интересные задачи, а остальных заставляет стараться свой рейтинг поднять. Оживленность и заинтересованность в команде резко прибавится, ненавидеть вас будут жестко, но ведь задача руководителя и не стоит в том чтобы быть хорошим дружбаном для разработчиков.
Правда такой подход достаточно экстремальный ) Он не для каждой команды подходит. Я лично использовал его для работы с удаленными сотрудниками, там и текучка больше. Те кто опускался в рейтинге вниз больше на проекты не приглашался.
При любом раскладе единственной значимой величиной является гарантийный срок, так как после него диски как правило меняют в любом случае, а вылет одного-двух дисков не является чем-то катастрофическим и опять же по гарантии они будут заменены, поэтому можно не запариваться по поводу значений MTBF и тд, они важны только для производителя чтобы подсчитать сколько надо будет заменить.
Конкретно для поиска гамильтонова пути это далеко не самый лучший алгоритм. Кстати не знал что он мембранным называется, хотя уже использовал, спасибо что просветили )
Может немного подробнее расскажете о персонале — продавцах, как искали, по каким критериям, каким образом обучаете, установленные условия работы. Это было бы очень интересно, а то персонал это вечная и самая большая проблема )
Странно вообще что такая негативная реакция у многих. Ваше что-ли раздают? Как-то неправильно считать чужие деньги. Тем более википедия проект некоммерческий и правильно что сервера просто раздает. А почему не в Африку как тут сказали, а в Америку — стоит прочесть иначе, они отдадут в Америке, то есть если вы из России и можете там забрать, почему бы нет я думаю, а весь гемор по доставке берите на себя — вполне адекватно. А то совсем обнаглели, мало того что сервер нахаляву, так ещё и доставить в подарочной упаковке с ленточкой и бутылкой шампанского для обмытия.
Ну может быть и наоборот — столько клиентов, что нет времени на сайт! ) Ну у меня так к примеру ( 6 лет на аутсорсинге, а сайт руки так и не дошли сделать, вечно в работе, да и собственно зачем он мне )
Что-то вы с циферками загнули. У меня лично другой опыт — москвичи поголовно жмоты мне попадались, при том что я аутсорсер и не делаю сайты под ключ у меня разработка для Москвы не выше 150к, а в Питере от 250к. И зарплаты здесь у младших программистов пыхапешников в фирмах (не всех конечно) по 50к, так что не гоните.
Хотя может для классической офисной работы такой вариант и не покатит, было бы интересно услышать мнения опытных офисных менеджеров и руководителей на этот счет, а ещё лучше произвести эксперимент )
Есть ещё маленький фокус, за который вас правда будут ненавидеть, но сроки ускорите если уж совсем жмет: конкурентная разработка — каждая задача решается двумя допустим людьми, или двумя командами если очень большая, после сдачи обе команды тестируют до чертиков работу противника ) По совокупности затраченного времени и количества выявленных багов начисляются баллы. В конце проекта по этим баллам назначаются хороооошие премии ) Ну и к тому же рейтинг программистов позволяет давать лучшим более интересные задачи, а остальных заставляет стараться свой рейтинг поднять. Оживленность и заинтересованность в команде резко прибавится, ненавидеть вас будут жестко, но ведь задача руководителя и не стоит в том чтобы быть хорошим дружбаном для разработчиков.
Правда такой подход достаточно экстремальный ) Он не для каждой команды подходит. Я лично использовал его для работы с удаленными сотрудниками, там и текучка больше. Те кто опускался в рейтинге вниз больше на проекты не приглашался.