dmitriy

1. Оценивать из опыта в нормо-часах
2. Закладывать риски от 10% до 30%. Соответственно, риски тем меньше, чем лучше вы знаете заказчика и его проект.

Нужно оценивать саму задачу, на сколько она сложна и сколько стоит выполнение такой задачи, а то сколько ты времени потратишь это уже не проблемы заказчика, как пример нужно сделать сайт, новичок 2 недели, средний программер неделя и это не означает что новичок должен больше просить так как он делал дольше. Как то так) Сроки это я так, чисто теоретически.

Крайне рекомендую читать вместе со ссылками: https://habrahabr.ru/post/276593/

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

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

сделай например для начала заготовку, авторизацию (простой интерфейс + табличку в базе), потом добавление задачи в црм (+ табличку для нее), для начала можно с простейшим дизайном.

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

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

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

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

Успехов.

Тыкали, пробовали, ставили с десяток этих систем, в том числе редмайн. Пришли к написанию собственной.

Enterprise Architect

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

из хорошей компании сотрудниу наврятли уйдет, видимо что то в вашей компании не так, что сотрудники не только валят, но ещё и клиентов уводят.
посмотрите вокруг

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

Чтобы люди не уходили, им должно быть интересно работать именно тут, и как удержать людей - условия зарплаты/работы должны быть не хуже, чем средние по рынку. А персональные вкусняшки - лучше.

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

а по мне так source tree - оч удобно. использую гит исключительно в одиночку, как бекап сорцов. нажать пару кнопочек удобнее, чем изучать все команды гит)

я делал что то подобное на Golang + Redis + Mysql за 4 вечера. Так что если вы говорите что у вас небольшая команда то думаю на пхп вы и за 3 вечера напишете своё. В любом случае это будет быстрее чем подобрать готовое под себя

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

Как по мне, то лучше уж привязка к CMS, чем такие велосипеды. Прочитать документацию CMS и внести правки будет куда быстрее, чем разобраться в очередном изобретении. К тому же CMS создаются для того, чтобы их могли использовать НЕ специалисты.

NetBeans.
Бесплатный. Работает с xDebug (правда, немного нужно почитать, как именно, но все равно).
Подсветка методов функций - работает (если правильно составлять phpDoc, конечно).
Минус - немного притормаживает, как и большинство редакторов на Java, и бывает раздражающее автодополнение, но, к счастью, запросто отключается.

Я приучился писать тесты просто: когда имеешь дело с деньгами - цена ошибки высока. Без тестов процессинг писать - лучше сразу застрелиться. Учился не сам - такова была политика тимлида.
Когда есть уже проект с legacy-кодом (а ваш именно такой по определению Боба Мартина), то единственный способ начать что-то менять это начинать писать тесты на новый функционал. А если доходят руки до рефакторинга, то тоже сразу покрывать этот код тестами.
Что касается заказчиков, то им действительно до лампочки есть тесты или нет. Поэтому надо оценивать время разработки таким образом, чтобы в него входило время на написание тестов. Как показывает опыт, никто не будет задавать вопрос "Почему так долго?". Если зададут, то можно ответить по типу "вы же не хотите услышать лекцию про устройство ядерного реактора?"

Мышь, клавиатура и чашка кофе.