Eine ganz normale Situation: Auf der Suche nach einem Auftragnehmer für die Entwicklung einer IT-Lösung sendet ein Kunde Anfragen an mehrere Unternehmen. Ziel ist es, über die Zusammenarbeit mit dem Auftragnehmer zu entscheiden, indem Vorschläge gesammelt und analysiert werden. Das Auswahlverfahren wird dadurch erschwert, dass sich Arbeitsumfang, vorgeschlagene Technologien und Preise erheblich voneinander unterscheiden. Es entsteht ein Problem, das oft nicht erkannt wird: Diese Vorschläge sind nicht nur ungleich, sondern bewerten auch unterschiedliche Lösungen.
Dieser Artikel bietet dem Leser einen systematischen Überblick über die Auswahl der Auftragnehmer. Unser Ziel ist es, die Suche nach innovativen Ansätzen zur Lösung von Problemen in der Phase der Problemformulierung und der Erfassung von Schätzungen anzuregen .
Im gesamten Text werden die Begriffe "IT-Lösung" und "Entwicklungsobjekt" synonym verwendet. Sie beziehen sich auf jede Software (Mobil-, Web-, Desktop-Anwendungen, Websites usw.), die während des Entwicklungsprozesses erstellt wird, um bestimmte Geschäftsziele des Kunden zu erreichen. Es gibt einen Begriff "Forschungsobjekt" - die Phase der Erstellung eines Entwicklungsobjekts bis zur Implementierung der Lösung.
Situation und Problem
Ein typisches Auswahlverfahren für Auftragnehmer ist wie folgt.
1. Leistungsbeschreibung
Ein Teil des Beschaffungsprozesses ist ein Dokument , beschreibt die Lösung - Aufgabenstellung (TOR). Der Manager des Kunden ist eine Person, die an Entwicklungsdienstleistungen interessiert ist (im Folgenden als Thema bezeichnet) und die TK an mehrere Organisationen sendet. Die Probanden in diesen Organisationen erhalten TK und bewerten die Arbeit anhand der festgelegten Anforderungen. ( Wie der Kunde einen technischen Auftrag erhält - siehe Abschnitt „Leistungsbeschreibung für das Studio!“ Ein Beispiel für eine „Situation nahe am Ideal“)
Schematisch sind diese Beziehungen wie folgt.
2. Reaktion von Organisationen und Analyse von Vorschlägen
Der Kunde erhält Angebote von potenziellen Auftragnehmern. Vorschläge sind ein Dokumentformat, in dem Arbeitsumfang, Fristen, Kostenvoranschläge, Beschreibung der Erfahrung und Teamkompetenz am häufigsten angegeben werden. Die Vorschläge werden nach einer Reihe von Kriterien geprüft und miteinander verglichen.
3. Liste der ausgewählten Organisationen
Basierend auf der Analyse der Vorschläge wird die Liste der potenziellen Auftragnehmer reduziert. Die endgültige Entscheidung wird nach Kommunikation mit jedem von ihnen und Diskussion der eingereichten Dokumente getroffen.
4. Vertrag
Unterzeichnung eines Servicevertrags mit einem ausgewählten Auftragnehmer.
In den Phasen 2 und 3 tritt häufig ein Problem auf: Dies wird durch meine Erfahrung in der Zusammenarbeit mit kleinen und mittleren Unternehmen belegt. Vorschläge mit unterschiedlicher Arbeitszusammensetzung und unterschiedlichen Schätzungen lassen den Eindruck entstehen, dass diese Daten für eine Entscheidung ausreichen. In diesem Fall werden die Auswahlkriterien auf Kosten und Arbeitsumfang reduziert.
Meiner Meinung nach bietet dieser Ansatz keine Voraussetzung für die Vollständigkeit und ausreichende Informationen, um eine Entscheidung treffen zu können. Es gibt kein bewusstes Verständnis der Situation und das Vorhandensein eines „unvollständigen“ Prozesses des Wissenstransfers über eine mögliche Lösung zwischen den beiden Themen.
Leistungsbeschreibung für das Studio!
Technische Zuordnung (TOR, technische Zuordnung) - Ein Dokument, das die Anforderungen des Kunden an das Beschaffungsobjekt enthält. Die TK legt die Bedingungen und Verfahren für die Beschaffung fest, gemäß denen die Lieferung von Waren, die Ausführung von Arbeiten, die Erbringung von Dienstleistungen und deren Abnahme durchgeführt werden.
Ich werde versuchen, die Definition zu vervollständigen.
Die Leistungsbeschreibung besteht aus einer Reihe von Artefakten, durch die formalisiertes Wissen über das Beschaffungsobjekt in diesem Kontext übertragen wird - Wissen über die erstellte IT-Lösung.
Um die Schritte 1 bis 3 zu analysieren, wollen wir nun kurz eine nahezu ideale Situation von Schritt 1 konstruieren. Derzeit gibt es auf dem Markt viele GOST-Standards zum Schreiben technischer Spezifikationen für die Entwicklung von Informationssystemen. Ich werde sie nicht beschreiben, sie sind alle gut entwickelt und haben ihre Vor- und Nachteile.
Nehmen wir an, der Kunde hat das Forschungsobjekt aus verschiedenen Blickwinkeln betrachtet, um die optimale Lösung zu ermitteln. Indem Sie verschiedene Projektionen untersuchen, können Sie die optimale Lösung finden. Bei der einseitigen Projektion wird nicht das gesamte Bild angezeigt. Wie in der folgenden Abbildung ist ein Zylinder in einem Vorsprung ein Quadrat und in einem anderen ein Kreis. Für verschiedene Personen ist die Lösung für dasselbe Problem unterschiedlich.
Sie können auch durch eine systematische Analyse des Problems zu einer optimalen Lösung gelangen, indem Sie ein Objekt mit funktionalen, genetischen, dynamischen und prozeduralen Projektionen untersuchen.
Schema 1 - Projektionen der Objektuntersuchung basierend auf dem 2. Konzept des Systems nach Dubrovsky.
Ich werde nicht auf diesen Ansatz eingehen, aber ich kann in den Kommentaren meine Erfahrungen mit der praktischen Anwendung teilen, wenn es Anfragen gibt.
So hat das Subjekt nach bestimmten Handlungen das Wissen gebildet, wie das Problem gelöst werden kann. Das Wissen kann unzureichend sein und die Probleme auf dem Weg zum Ziel können unterschiedlich sein, aber das Wissen existiert in einem bestimmten Umfang.
Wie übertragen wir Wissen über die Lösung?
Lernen - der Erwerb von Wissen, Fähigkeiten, Fertigkeiten - erfolgt in mehreren Phasen: Produktion, Akkumulation, Verteilung, Nutzung.
Abbildung 2 - Lernschritte
Betrachten Sie dieses Diagramm in Bezug auf den Prozess der Interaktion mit Auftragnehmern.
- Implizite Wissensproduktion. Bei der Herstellung werden Informationen aus verschiedenen Quellen gesammelt: Empfehlungen von Beratern, Wettbewerbsforschung, persönliche Erfahrung bei der Entwicklung von IT-Lösungen, Informationen zur Organisation von Objekten rund um das untersuchte Problem und vieles mehr. Implizites Wissen wird nicht formalisiert, d.h. in keiner Weise ausgedrückt. Mit einfachen Worten, implizites Wissen ist in der Erinnerung des Subjekts, des Managers eines Unternehmens, das an Entwicklung interessiert ist.
- . . , — ! — , , , , . , , , , , - , . , . .
- . , . , (, , ..). . , , , N ( ).
3 — . - . , , , , .
Checkliste mit Projektionen zur Formalisierung des Wissens und zur Beschreibung von Situationen vor der Auswahl eines Auftragnehmers
Um Managern und Managern dabei zu helfen, Fehler beim Erstellen und Übertragen technischer Spezifikationen zur Bewertung an IT-Auftragnehmer zu vermeiden, schlage ich eine Liste von Projektionen vor, um das Wissen über eine IT-Lösung zu formalisieren, und eine Checkliste mit Beschreibungen von Situationen, die bei der Anwendung des von mir beschriebenen Schemas „Lernphasen“ hilfreich sind.
Meiner Meinung nach sollte eine IT-Lösung aus mindestens 4-5 Positionen in Betracht gezogen werden, um ein möglichst vollständiges Bild zu erhalten.
Checkliste Nr. 1 - "Liste der Projektionen"
- Beschreibung der Situation um das Objekt im Rahmen der Aktivität zum Zeitpunkt der Studie: wie Menschen arbeiten, welche Arten von Aktivitäten sie ausführen, welche Schwierigkeiten auftreten usw.
- Funktionsprojektion bezüglich der Hauptrollen in der Lösung.
- Nichtfunktionale Projektion mit Modell technischer Merkmale, die die Entscheidung beeinflussen.
- Geschäftsprognose in Bezug auf die Hauptakteure, wobei das Ziel durch die Methode und das Ergebnis formuliert wird.
- Visuelle Projektion des Lösungsprototyps (vorausgesetzt, Sie haben die Forschungsphase des Prototyps bereits bestanden).
Natürlich kann es mehr Positionen und Projektionen geben, und jemand wird sagen, dass sich diese Checkliste in Bezug auf die Branche, Aufgaben usw. ändern wird. Höchstwahrscheinlich wird dies so sein, aber meine Hauptaufgabe besteht darin, mich auf die methodischen Grundlagen zu konzentrieren. Sie können also überall verwendet werden und Checklisten für jede Situation erstellen.
Arten von Situationen, in denen sich ein Manager möglicherweise befindet, bevor er Auftragnehmer anzieht:
- Sie möchten etwas Nützliches tun, verstehen aber nicht genau, was.
- , . .. , , , . , .
- , , . .. , . , : , , , ...
- , ( = + ), 1- , - №1.
- , 4-5 , - № 1.
- , - . , 1-5 .
Ihre Aufgabe ist es, zu Punkt 4 oder Punkt 5 zu gelangen. Gleichzeitig müssen Sie in jeder Phase unbedingt Wissen produzieren und ansammeln. Sie sollten sowohl formalisierte als auch nicht formalisierte Produkte Ihrer Aktivität haben: Diagramme, Beschreibungen, persönliche Fähigkeiten und Erfahrung in der Funktionsweise, Beschreibungen anhand der Positionen der Checkliste Nr. 1. Und wenn Sie zu Punkt 4 kommen, besteht Ihre Aufgabe darin, Wissen zu verbreiten - es an Ihre Auftragnehmer und Partner weiterzugeben.
Die Verbreitungsphase enthält meistens die folgenden Verfahren: Analyse, Diskussion und Assimilation.
Wenn Sie die TK gerade an Auftragnehmer gesendet haben, um die Preise zu überprüfen und den Arbeitsumfang zu analysieren, ist dies gleichbedeutend mit dem Versuch, auf einem Stuhl zu sitzen, ohne ihn unter Ihren Hintern zu legen. Jemand mag Glück haben und er wird sich setzen, aber für jemanden wird es unangenehme Konsequenzen geben =)
Stellen Sie sich also eine Frage: Wie, wenn Sie einem Auftragnehmer Wissen über Ihre Situation übertragen:
- Analysieren Sie formalisiertes und nicht formalisiertes Wissen über das Übertragungsobjekt
- Besprechen Sie mit dem Auftragnehmer formalisierte und nicht formalisierte Kenntnisse über das Übertragungsobjekt
- assimilieren dieses Wissen.
Einige der Leser werden sagen, dass es schwierig und oft physisch unmöglich ist, diese Verfahren durchzuführen, wenn TOR versandt und Preise von Auftragnehmern gesammelt werden. Ich stimme ihnen vollkommen zu. Aber ich denke, dass die Ziele falsch formuliert sind.
Wenn ich einen Auftragnehmer finden muss, sollte die Suche durch die Recherche von Auftragnehmern erfolgen. Daher können wir dieselbe Systemanalyse und beispielsweise Schema 1 anwenden, um ein Programm zur Erreichung dieses Ziels zu planen. Und höchstwahrscheinlich werden sich die Aufgaben ändern und sich stark von den im Abschnitt „Situation und Problem“ beschriebenen Schritten unterscheiden.