古いプログラマは姿を消した。別のプログラマーを雇おうとしています。これにどのようにアプローチしますか?[閉まっている]


19

WordPressBuddyPressを使って私のためにソーシャルネットワークプロジェクトに1年以上費やした後、私のプログラマーは、週ごとに報酬を受け取っていたにもかかわらず、全期間にわたって姿を消しました。はい、私はメールトラッカーを使用して確認し、私のメールを開いているのを確認したので、彼は死んでいませんが、彼は応答しません。彼は別の仕事を得たようです。なぜ彼はそう言うことができなかったのだろうか。そして、私は彼がやったことのない仕事のために彼に事前給料を支払った。

問題は、彼がコーディングしたほとんどの関数の完全なドキュメントを求めたことがないことです。そして、この1年以上の期間には多くの関数があり、それらのいくつかにはまだ修正しなかったバグがあります。今ではすべて混乱しているようです。

最初にすべきことは何ですか?どうすればいいですか?

最初にやるべきことは別のプログラマーを獲得することだと思いますが、プログラマーが問題なくすべての機能に取り組むことができるように、現在のすべてのコードを文書化することから始めましょう。

それが最初にすべきことですか?はいの場合、どうすればいいですか?

このようなものに必要な標準的なドキュメントは何ですか?すべてのコードのドキュメントを作成してバグを修正するだけのプログラマを入手できますか、それともドキュメントは本当に重要ではありませんか?

また、別の「個人」プログラマーを取得する方が良いと思いますか、それとも私のプロジェクトに割り当てられたプログラマーが消えた場合、別のプログラマーが彼の代わりになりますように、彼らのために働くプログラマーを持っている会社を取得しますか?これが最初に取るべきアプローチだと思います。


29
「そして、私は彼がやったことのない仕事に対して彼に前給を支払った。」-それが彼を訴える理由かもしれません、あなたは弁護士を確認する必要があります。
Doc Brown

残されたソースコードを理解する上であなたがどれだけ熟達しているかについての詳細を教えてください
マル

10
最も重要な最初の質問:契約はありますか?
ラドゥムルゼア

5
私が置換プログラマである場合、私が望んでいるドキュメントは、スコープ、マイルストーン、問題の説明など、彼が働いていたものです。彼のコードは、おそらく私ができる限り分析できなかった誰かによって「文書化」されました。
user16764

15
まず、サーバーへのログインとパスワードを変更します。
マイケルライリー-別名ガニー

回答:


17

私たちがコメントで行った相互作用に基づいて、私はあなたが個人的なもののためにあなたの唯一の開発者を追い払わなかったという仮定で行きます。しかし、その会話に基づいて、このset折は依然として雇用管理者としてのあなたの責任であると推測します。あなたが言ったように、開発者との経験はまったくありませんが、開発者をどのように決定するのですか?

あなたはベストを尽くしたように聞こえますが、あなたは単にこのプロジェクトの規模を処理できない人を雇い、彼は彼の下で崩れた不安定な基盤を構築し、彼は単に去りました。残念ながら、開発者と起業家の違いは、前者が時間給/給料を受け取ることですが、好きなように出入りすることを選択できることです。彼は彼が働いていた時間の給料をもらって、もう給料を受け取らないことを選んだときに去りました。あなたはそれについて何もできません。

ならどうしよう?人々をプロセスに置き換える道を歩み始めたようです。あなただけが十分なドキュメントを持っていれば、人々は去ることができ、他の人は中断したところから取り戻すことができます。動作しないIMOは、動作する場合でも、正社員の信頼できるチームを持つよりもずっと高価になります。過去30年間にわたるさまざまな企業の経営陣は、人々を十分なドキュメント(私の最後の仕事を含む)に置き換えようとしましたが、毎回失敗しました。だからこそ、私は転職を決めたのですが、今では彼らは時代遅れで正確ではない文書で立ち往生していますが、新しいスタートアップで人生を過ごしています。

もし私があなただったら、このプロジェクトを手に入れて完成させるのに十分なスキルと経験を持つ適切な人を見つけようとするでしょう。これには、コーディングスキルだけでなく、設計、アーキテクチャ、および基本的なプロジェクト管理も含まれます。彼が自分の仕事をどのように行うか、または彼が作成する必要があるドキュメントの数を定義しようとしないでください。適切な人を見つけることに集中し、それに応じて支払う準備をしてください。あなたが彼を見つけたら、あなたの役割が彼を支援し、彼の方法から障害物を取り除くことであることを確認してください。私はあなたがそれを以前にやったことを暗示しているわけではありませんが、多くのマネージャーがそれをする傾向があり、それは単に生産的ではないことを知っています。

他の起業家、おそらくソフトウェアエンジニアリングのバックグラウンドを持つ起業家に相談してください。これらのフォーラムを読んで、あなたの将来の雇用を尋ねる質問のセットを考え出してください。問題を提示し、アプローチがどうなるか尋ねます。彼が適切な人物である場合(そして、このページが表示されなかったと仮定すると)、彼は、あなたが回復し始めたときにあなたの会社ですべきことに関して他の人がすでに提案した多くのことを提案できるはずです。彼が雇われてからv1.0が出荷されるまでの計画を定義するように依頼します。彼はどのようにそこに着くでしょう。そのような人にインタビューするのを助けてください。

私の考えのほんの一部:バグ追跡は必須です(Jiraは10人までのチームで10ドルかかります)。ソース管理は必須です(gitは無料です。最大5人程度のチームの場合、perforceにはピーナッツがかかります)。コードはドキュメントです。文書ではありません。彼はコードをレビューし、救助可能なものを保持する必要があります。残りを捨てて、保守可能で読みやすいコードを書くことに集中してください。いくつかの高レベルで数ページのデザインドキュメントのドキュメントを保存します。彼はあなたが取り組んでいる技術を知っていなければなりません。善意で誰かを雇わないでください。あなたの時間に彼らに学ばせることはできません。彼らに他にどのようなプロジェクトを行ったか尋ねてください(残念ながら、あなたやあなたが見つけた誰かが技術的な側面に追いつく必要があるかもしれません)。あなたは十分な経験を持つ人を探していますが、その興奮の火花がすでに燃え尽きているほど多くはありません。インパクトを与えることに飢えている人を見つけましょう。彼が提案または従う方法論により、定期的に(1週間または2週間)作業を確認し、即座にフィードバックを提供できるはずです。正確に7.4か月で準備が整うと言う人を雇わないでください。完了したらお知らせします。

がんばろう


1
@pocto:人々はそこにいますが、あなたは... a)彼らにお金を払うb)彼らを見つけることができる必要があります(残念ながら、私は見たことがないのでそこにあなたを助けることはできません)。しかし、あなたが適切な人を見つけたら、彼は既存のウェブサイトを含む現在の状況を調べて電話をかけます。既存のバグを修正し、既存の顧客を維持することは間違いなく重要です。それが彼の今後の計画の一部であることを確認してください。あなたが考慮すべきもう一つのことは、あなたが本当にあなたの会社の大部分を運ぶ誰かを見つける必要があるということです。たぶんだけではなく、従業員のために見て...を探して
DXM

1
... パートナー。報酬パッケージの一部として、会社の一部を提供します(20〜30%でしょうか?)。成功した場合、20%減少しますが、失敗した場合、0が20%増加しても何の効果もありません。彼は(つまり、ウェブサイトを成功させるだけでなく、コレクト毎週給料)あなたと同じような興味を持っていることを確認するためにあなたの新しい従業員/パートナーを奨励して、このかもしれないのヘルプ
DXM

1
Pocto、ここに提示された意見のいくつかは、広く受け入れられていません。たとえば、同じ開発チームが永遠に存在すると、多くのことが単純化されますが、(ご存じのとおり)それを保証することはできません。そのため、ドキュメントと適切なコードが必要であるため、他の人はより低い(しかしそれでもかなりの)コストで介入できます。「興奮の火花は燃え尽きていない」というのは、純粋なアジミズムのように思えます。ソフトウェア開発の管理は難しい-良いプログラマと悪いプログラマを区別するのは難しいだろう、と私は恐れている。
psr

@psr:優れた設計ドキュメントを含む読み取り不能なコードよりも、適切な命名/構造と高レベルの設計ドキュメントを備えた適切に記述されたコードをいつでも受け取ります。そして、私はagist(sp?)であることを意図していませんでしたが、私たちの職業は絶え間ない学習と成長を必要とし、技術の多くはあなたの下でシフトするので、多くは仕事だけではできません。しかし、私よりも若い人も年配の人も多く見ています。彼らはやがて「十分に学んだので、今は仕事をします」と言うようです。私はその岩よりもずっと年上な人を見たことがありますが、彼らはただ40時間働く以上のことをします。
DXM

13

これは奇妙な状況であり、あなたはあなたが全体の話をしていないと確信しています。私は多くの人々と仕事をしましたが、何人かはさまざまな理由で去りました(私は同僚です)。

しかし、それは問題ではありません。少なくとももうありません。あなたは自分の過ちから学び、将来それを繰り返さないようにするべきです。そして、はい、私は50%が彼/彼女が去ることのあなたのせいであることを強く提案しています。

現在の問題の解決について:

  1. プログラマーに連絡してみてください。彼はあなたのメールを読みます-最も重要なバグを文書化/修正するためのお金を彼に提供します。誰も彼より早くそれらを修正することはできません。機能しませんか?彼が働いている場所を見つけて、その会社に連絡してあなたの話をしてみてください。良い会社は、彼らのために同じことをすることができる人を雇いません。少なくとも彼らはあなたのために文書を完成させるように彼に言うでしょう。

    注:その人を元に戻したくないので、完成したドキュメントが必要です

  2. あなたの1年分の仕事が無効になることを覚悟してください。あなたが結果を求めたときに彼は逃げたかもしれず、彼は彼が配達できないことを知っていました。コードがハッキング、汚れた実装、および全体的な品質低下に満ちている可能性があります。彼が戻ってきたとしても-彼はおそらくスキルも、それを正しく行う時間さえないでしょう。

  3. 別の人を探してください。彼は同じテクノロジー(プログラミング言語、フレームワークなど)を知っている必要があります。コードの品質が良い場合-彼は続行できますが、そうでない場合は、彼はそれをリファクタリングすることができます。はい、リファクタリングには新しい機能の実装がないため時間がかかりますが、コードを保守可能にし、それが必要です。さらに、悪いコードをリファクタリングできる人は、本当に良いプログラマです。

    注:前払いするのは愚かなことです。給料の全体的な考え方は、仕事を済ませることです。約束されたものではありません:)

  4. リストを作成します。計画を立てることはあなたの最大の利益になります。一度読んだ技術仕様により、新しいプログラマーは仕事とマイルストーンを理解できます。少なくとも3つの重要なドキュメントがあります。

    • プロジェクトの全体的な説明-非プログラマーでもプロジェクトの内容を知ることができるドキュメント。

    • タイムライン-いつどこで準備ができると期待していますか?すでに何が行われていますか?

    • 技術仕様-これは長いものです。プログラマーが読みたいドキュメントです。論理的な部分に分けて、その特定の部分の機能とワークフローをできる限り詳細に説明します。

企業と仕事をするのは、それほど良いことではありません。あなたのチャンスは良くなりません。プログラマーを1人だけ雇うと、10倍の費用がかかります。あなたが小さなチームを持っているなら、例えば3〜5人、チームリーダーになりたいプログラマーを雇ってください。彼はチームを管理するより良い仕事をするでしょう。


15
彼の新しい会社に連絡して、彼について話すことはお勧めしません。真実かどうかはともかく、少なくとも米国では、名誉ation損訴訟の可能性を生み出しています。
GrandmasterB

3
良い答えですが、...「給与の全体的な考えは、仕事を終えたときに支払うことです」..その国はどこですか?(他の問題の中でも)1行のコードを変更せずに、チームに参加して1か月を費やしただけです。1か月分の給料を支払いましたが、いつ彼が生産的になるか分からなかったので、彼を解雇しなければなりませんでした。私自身の経験では(ディルバートを反映しています)私は仕事に来て、お尻を片付けるか、一日中歩き回って話をして、まったく同じ給料をもらえます。
DXM

@DXM、あなたは部分的に正しい:あなたの仕事がそれに値しないとしても、あなたは月の給料を得るでしょう。しかし、それは政府による保護の効果です。それは良いことですが、常にそれだけではありません。そして、あなたが言ったように-怠け者は長い間彼/彼女の位置を保つことができなくなります。しかし、私はあなたの意見にほぼ同意します。
クリエイティブマジック

この人が働いている新会社に連絡するためには、-1にする必要があります。彼らが仕事を失った場合、彼らはあなたを訴えることができます。さらに重要なことは、苦い人からのドキュメントやコードの修正は品質が非常に悪いため、そもそもそうしたくないでしょう。
MrFox

8

後で別のプログラマーがコードを文書化しますか?あなたがその道を取るべきではないと言うのは、単に私自身の経験と意見です。

そのコードベースの品質に関するより詳細な知識がなければ、私の意見では、バグを修正し、必要に応じて修正を行うために新しいプログラマーを雇うことが最善のアプローチであると考えています。

その意見には、要件を満たす必要があるため、可能な変更(変更または追加)のキーポイントがあります。これは、何らかの要件仕様を作成する必要があることを意味します。これはドキュメントです。

これは、プロジェクト全体を維持するポイントにつながります。現在のプログラム要件や大まかな機能文書が存在するかどうかは質問で伝えませんでしたが、ここで焦点を合わせる必要があります。

この時点でドキュメントがまったくない場合は、その空白を埋めるのはあなた次第です。プログラマを雇ってアプリケーションをリバースエンジニアリングし、そこからドキュメンテーションを奇跡的に作成することはできません。プログラムに何をさせたいかを「説明」する必要があります(既にプログラムされているものを再説明することを意味する場合でも)。

そのドキュメントを(要件仕様または機能仕様の形式で)作成すると、ドキュメントを引き渡し、そこから作業を開始できるため、新しいプログラマを採用することでより良い結果が得られます。

また、ソースコードからドキュメントを作成するプログラムが多数あります。これは、実際のソースコードを説明するスケルトンを作成するのに適した方法です(これは技術仕様の領域にあります)。機能仕様で指定された機能。要件仕様で指定された要件の機能を指定します。

そう、私の意見では、バグを修正するためにプログラマーを雇うことです。あなたが修正すべきであることに同意したバグを彼が修正した後、別の契約として文書化の側面について議論することができます。幸運なことに、ある程度の経験があり、そこから次にとるべきステップに貢献できるプログラマーを雇いました。


それは非常に包括的で有用な答えです、Raybarg。あなたが言ったことは非常に理にかなっていると思います-最初に既存のバグを修正するために別のプログラマーを雇ってから、別の契約として側面を文書化することについて議論すること。私はプログラマーがバグを修正した後、長期的にプログラマーがいることさえ望んでいるので、これはうまくいきます。
ポクト

@Raybarg「バグを修正した後、コメントする」について:バグを修正している間はコメントすることをお勧めします。結局のところ、その段階では、文書化するためにすべての知識を収集します。したがって、すぐに書き留めてみませんか?より多くのバグをより早く見つけて修正するのに役立ちます。
マルセル

@Raybarg、「ソースコードからドキュメントを生成するプログラム」についてここで言ったことについて詳しく説明してください。本当に?これらのプログラムはどのようなもので、どのように機能しますか?
ポクト

3

ここに私が問題にアプローチする方法があります:

  • ドメインの知識があります。現在、Webサイトで利用可能な機能、将来追加する機能を知っており、おそらくユーザーから報告されたいくつかのバグもリストできます。

  • そこに座っているコードの山があり、隅にそれ自体が残っています。バグがあるかもしれませんが、サイトにはアクティブユーザーがいるため、依然として価値があります。したがって、完全な書き換えは間違いIMOになります。

ドメインの専門知識とコードの橋渡しは、プログラマーが去ったときに壊れていました。コードベースを要件と再度同期し、将来の更新を開発できるように、再構築する必要があります。

問題は、そのブリッジを完全にドキュメントで作成することはできないということです。ソフトウェアは技術的であると同時に人間の問題です。新しいプログラマーに期待することを非常に詳細に説明しないと、コードだけからそれを推測するのに苦労します。また、新しいプログラマと密接に連携してコードが要件に一致することを確認する自動化された継続的な方法を見つけない場合、つまりブリッジをより堅牢にするために、問題は繰り返されます。

  • ドメイン知識処理セッションのために、新しいプログラマーと定期的に(事実上であっても)座ります。これらの各セッション中に、製品のごく一部の仕様を一緒に書きます。単一のWebページでも機能でもかまいません。それらを実行可能な仕様にする(Behavior-Driven Developmentに似た)ことで、ブリッジが機能するという自信のレベルが上がります。これは、それらを継続的に実行し、何か問題があるときに警告を受けることができるからです。また、開発者の生活が楽になります。

    セッションの後、開発者は作業に戻り、現在のコードが仕様に準拠していることを検証する低レベルのテストを作成できます。準拠していない場合、プログラマーはそれを修正するために必要なものをすべて持っています。また、彼が持ちうる質問にいつでも利用できるようにすることも重要です。

  • あなたとあなたのプロジェクトのプログラマーとの間の緊密で継続的な共同作業を維持し、これが彼らの間でも真実であることを確認してください。これは、プロジェクトの機能的および技術的文化を存続させ、現在のような問題を回避する場合に必要です。もちろん、これにはプロジェクトで作業する2人以上の開発者だけでなく、作成するすべての知識を互いに共有する必要があります。したがって、他の人が行方不明になったときに、フェイルオーバーとして機能できます。などのテクニックペアプログラミングコードレビューは、それを達成するための良い方法です。

1

誰もが言ったことに加えて、

古いプログラマーに自分のコードを高価でも文書化できない場合は、他の誰かがそれをより良く文書化できると期待しないでください。そこで、新しいプログラマーを初日に生産的にするために今できることについて、いくつかのオプションを紹介します。

  1. バグデータベースを取得し、見つかったすべてのバグの入力を開始します。これはプログラマーの優先事項です。それを適切に文書化し、可能な限り詳細に入力します(ソースファイル/根本原因、その動作、および行うべきこと)。BugzillaRedmineなどの多くの無料のバグ追跡ソフトウェアがあります。 JIRAは。好きなものを自由に使用してください。
  2. プロジェクトの仕様書を作成します。これにより、バグが解消された後、新しいプログラマーに何らかの方向性が与えられます。チェックアウトできます仕様の記述に関するJoelのガイドをご覧
  3. プロジェクトのスケジュールまたはタイムラインを作成します。前もって支払うのではなく、提出した作業に対して支払いを受ける期限とマイルストーンが必要です。

これで問題は解決したので、プログラマーを探し始めることができます。そして、Creative Magicが言ったように、仕事を企業にアウトソーシングすることは、惨事につながるか、価格を無限に超えてしまう可能性があります。

今回は、バスファクターを適切に計画し始めますプログラマーを雇う際に。人々が行き交い、あなたがそれについてできることは何もないので、今回は最悪の事態に備えて、プログラマーを2人、またはUoooが言ったように1人のプログラマーと1人のテスターを取得します。

さて、プログラマーがあなたと一緒に店に来たら、古いコードを文書化するように頼むのではなく、今後のコードを文書化するように彼らに頼むことができます、本当に、それを忘れてください。

新しいプログラマーを獲得する際に考慮すべきその他のことは、彼らがソース管理と自動化されたテストを知っていることを確認してください。また、Joel Testでできる限り多くのチェックを行って、彼らの助けを借りてください。これは自分でできることです。


0

だから、あなたの唯一のプログラマがバス見舞われたので、今すぐ交換が必要です。

若手の契約に基づいて、元プログラマを訴えたり、彼の何が悪いのかを見つけたりすることができます。彼が戻ってきないと仮定すると、これはあなたを助けません。

  • 製品を完成させたいので、既存のシステムの保守と開発の経験があるプログラマーを探してください。私はあなたのプログラマーに何を何の順番で行うかを伝えることに集中しません。必要に応じてドキュメントとユニットテストを作成する専門家を必ず雇用してください。
  • あなたの側から、新しいプログラマーが彼の仕事に必要なものすべてを持っていることを確認できます :要件仕様、強力な作業マシンなど。あなたはプロのプログラマが欲しいので、彼にプロの作業環境を提供してください。

また、この種の困難な状況を将来より簡単にするために、2人目の開発者を雇うことを考えてください。テスターは品質保証にも役立ちます。


答えてくれてありがとう、Uooo。特に、将来このような状況を簡単にするために、2人目の開発者を雇うという部分が気に入っています。しかし、2番目の開発者の仕事は何でしょうか?
ポクト

@poctoソフトウェアの保守と開発。書かれているように、私はあなたのプログラマーに何を何の順番で行うかを伝えることに集中しません。バグを修正する必要がある場合、これを行う必要があります。新しい機能と単体テストを実装する必要がある場合、ドキュメントを作成する必要があります。これを行う必要があります。「バグ修正者」、「ドキュメント作成者」、「機能実装者」を雇うのではなく、ソフトウェア開発者を雇います。そして彼の仕事はそれをすべてすることです。
うおお
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.