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